Program file measurements for context-specific authentication

Abstract

The present disclosure relates to a program file measurement for context-specific verification. In some examples, during runtime of a virtual computing environment, a system intercepts an invocation of an enabling of a program file related to program execution in the virtual computing environment and obtains context information of the virtual computing environment for the program file prior to enabling the program file in response to the invocation. The context information includes an identifier of a program code image of the virtual computing environment. The system computes a measurement value based on the program file and provides the measurement value and the context information of the virtual computing environment to an integrity checker to perform context-specific verification of the program file.

Description

Background Technology

[0001] A computer system can execute programs (including machine-readable instructions) to perform a targeted task. Programs can include operating systems (OS), applications, scripts, firmware, services, and / or other types of programs. Programs can be corrupted, such as by attacks that modify program files or replace them with unauthorized program files. Additionally, an attacker may introduce unauthorized program code that can perform unauthorized actions on the computer system. Attached Figure Description

[0002] Some embodiments of this disclosure are described with reference to the following figures.

[0003] Figure 1 It is a block diagram based on some examples of the layout of computers and security engines.

[0004] Figures 2 to 4 It is a message flow diagram based on some example processes.

[0005] Figure 5 It is a block diagram of a storage medium with machine-readable instructions based on some examples of storage.

[0006] Figure 6 It is a block diagram of a system based on some examples.

[0007] Figure 7 It is a flowchart based on some examples.

[0008] In all the accompanying drawings, the same reference numerals refer to similar but not necessarily identical elements. The drawings are not necessarily drawn to scale, and the dimensions of some parts may be enlarged to illustrate the examples more clearly. Furthermore, the drawings provide examples and / or embodiments consistent with the description; however, the description is not limited to the examples and / or embodiments provided in the drawings. Detailed Implementation

[0009] Computer systems can execute programs in virtual computing environments that can be isolated from each other. In some examples, a virtual computing environment may include containers or virtual machines (VMs). A VM includes a guest operating system (OS) and other programs running in the context provided by the guest OS. Different VMs in a computer system can run their respective guest OSs. A hypervisor or virtual machine manager (VMM) is provided in the computer system to manage VMs (e.g., create VMs, unload VMs, etc.) and to manage the virtualization of the computer system's hardware resources.

[0010] Containers in a computer system do not have their own operating system; instead, they run on the host OS of the computer system. Programs (e.g., applications or other services) can execute within the corresponding container. Because containers do not have to run a guest OS, and further, do not need to deploy a hypervisor or VMM, containers provide a "lightweight" virtual computing environment. Examples of computing environments that provide containers include Kubernetes clusters. A Kubernetes cluster consists of compute nodes on which swarms (pods) of execution run, where each pod can include a collection of containers (a single container or multiple containers). In further examples, containers can run directly on bare metal servers or in VMs.

[0011] More generally, a virtual computing environment defines an isolated environment in which a corresponding program is executed. A virtual computing environment is part of the virtualization layer and can share the resources of a computer system (including hardware resources, program resources, etc.).

[0012] An attacker (e.g., a person, program, or machine) can cause unauthorized actions to be performed within a virtual computing environment. For example, an attacker could introduce unauthorized program code into the virtual computing environment. As a further example, an attacker could modify or replace program files associated with the virtual computing environment. "Program file" can refer to a file containing program code (scripts, source code, or executable code), data, and / or a configuration file containing configuration information for the program, and / or any other type of object or collection of objects that affects how the program is executed. As an example, in a computer system running a container, program files can include or be included in a container image that defines the container and the programs running within it. Program files can also include other files that can be enabled during program execution within the container.

[0013] In some examples, an integrity management system can be used to check the integrity of program files (such as container images). For instance, an integrity management system can verify the integrity of a container image before executing the corresponding container. Verifying the integrity of a container image can include any one or a combination of the following: checking the validity of the digital signature associated with the container image, calculating a checksum (e.g., a password hash or another value) based on the content and attributes of the container image, and verifying that the checksum indicates the container image has not been tampered with, and / or other verification tasks.

[0014] While an integrity management system that verifies the integrity of a container image before execution can prevent container execution based on a corrupted container image, it may not be able to protect a container after execution has begun (referred to as the container's "runtime"). An attacker can compromise a container after it has been verified and deployed based on that verified image. During the container's runtime, an attacker can compromise the container by altering program files used by the container, suppressing the execution of certain actions, modifying data values ​​or their arrangement, leaking confidential data, and / or injecting unauthorized code into the container.

[0015] According to some embodiments of this disclosure, a runtime protection mechanism supports runtime integrity checks for virtual computing environments (such as containers). During the runtime of the virtual computing environment, the runtime protection mechanism intercepts the enabling of program files related to program execution within the virtual computing environment and obtains context information about the program files and the virtual computing environment before executing or modifying the program files. Context information includes an identifier of the program code image of the virtual computing environment (e.g., a container image identifier), and other possible context information. The runtime protection mechanism calculates measurements based on the program files and provides these measurements and context information to an integrity checker to perform context-specific verification of the program files. When a program file is enabled during runtime, the runtime protection mechanism performs verification of the program file before allowing its enabling.

[0016] Runtime protection mechanisms can protect the virtual computing environment during its runtime after deployment on a program image (e.g., a container image) based on the virtual computing environment. Furthermore, by obtaining context information about the activation of program files that affect the operation of the virtual computing environment, integrity checks performed on program files can vary based on the context associated with the activation of the program files. Context-specific integrity checks can apply different strategies for different contexts. For example, an action that might be permitted in one context might be prohibited in another. In this way, the flexibility of integrity checks for program file activation is enhanced because different strategies can be applied to integrity checks for different contexts.

[0017] Furthermore, the ability to obtain context information for enabled program files allows runtime protection mechanisms to understand the context of each virtual computing environment (such as a container). Traditional integrity management systems are not container-aware; that is, they cannot determine the context for each container and therefore cannot perform integrity checks on individual containers.

[0018] Figure 1This is a block diagram of an example arrangement including computer 102 and a security engine 104 located remotely from computer 102. In other examples, security engine 104 is part of computer 102. Security engine 104 is used to verify the integrity of programs running on computer 102. Computer 102 may also be referred to as the "host computer," which hosts the execution of programs within computer 102 (such as in a virtual computing environment). Although Figure 1 A computer 102 is shown, but in other examples, there may be multiple host computers, and these multiple host computers are verified by security engine 104.

[0019] As used herein, "engine" can refer to one or more hardware processing circuits, which may include any or a combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or other hardware processing circuits. Alternatively, "engine" can refer to a combination of one or more hardware processing circuits and machine-readable instructions (software and / or firmware) executable on one or more hardware processing circuits.

[0020] In some examples, computer 102 can execute programs within corresponding containers (including containers 111, 112, etc.). Although containers are mentioned in some examples, it should be noted that the techniques or mechanisms according to some embodiments of this disclosure can be extended to protect programs executing in other types of virtual computing environments (such as VMs). Furthermore, in some examples, containers 111, 112 can execute within VMs. More generally, computer 102 can execute programs within a collection of virtual computing environments (including a single virtual computing environment or multiple virtual computing environments). As used herein, a “collection” of items can refer to a single item or multiple items.

[0021] Containers 111 and 112 in computer 102 run on OS 106 of computer 102. Since OS 106 is the operating system of computer 102, it can also be referred to as the "host OS." For example, a host OS is different from a guest OS running in a VM. In some examples, OS 106 includes a Linux OS. In other examples, other types of OS can be used, such as Windows OS, UNIX OS, Mac OS, Android OS, iOS, etc.

[0022] Computer 102 comprises several layers, including user space 108, kernel space 120, and hardware layer 122. Hardware layer 122 includes hardware resources such as storage medium 152, memory 154, and Trusted Platform Module (TPM) 156. Storage medium 152 may be implemented using a set of storage devices (a single storage device or multiple storage devices), such as disk-based storage devices, solid-state drives, etc. Memory 154 may be implemented using a set of memory devices (a single memory device or multiple memory devices), such as dynamic random access memory (DRAM) devices, static random access memory (SRAM) devices, flash memory devices, etc.

[0023] The TPM 156 is an example of a security processor capable of performing various hardware-based security-related tasks. For example, the security processor can perform various cryptographic operations. The security processor may also include security mechanisms that prevent tampering, making it impossible for malicious programs to modify the security tasks performed by the security processor. In some examples, the TPM 156 may be a hardware component or part of a hypervisor virtualization platform.

[0024] User space 108 includes containers 111, 112, and other components (discussed further below). Kernel space 120 includes the OS kernel 124 of OS 106. OS kernel 124 is the core of OS 106 and controls the resources of computer 102 (hardware resources, program resources, etc.). OS kernel 124 also manages the interaction between the hardware and programs of computer 102. In some cases, a portion of OS 106 may reside in user space 108.

[0025] Kernel space 120 is reserved for running programs with specified higher privileges than other programs (including OS kernel 124). Programs with lower privileges than OS kernel 124 execute in user space 108. Programs with higher privileges can perform certain operations and access certain resources (e.g., hardware resources, program resources, data, etc.) that are not available to programs with lower privileges.

[0026] According to some embodiments of this disclosure, runtime protection mechanisms are provided to protect the integrity of containers 111 and 112 during runtime. The runtime protection mechanisms include both internal host portions within computer 102 and remote portions external to computer 102.

[0027] like Figure 1As shown, the host-internal portion of the runtime protection mechanism includes a kernel-space runtime protection module 126 implemented with machine-readable instructions executed in kernel space 120, and a user-space runtime protection module 128 implemented with machine-readable instructions executed in user space 108. In some examples, the kernel-space runtime protection module 126 may be part of the OS kernel 124. In other examples, the kernel-space runtime protection module 126 may be separate from the OS kernel 124. In some examples, the user-space runtime protection module 128 may be executed as part of a container or outside of a container.

[0028] The external portion of the runtime protection mechanism includes a security engine 104, which performs integrity verification of the program files within computer 102 when the program files are enabled by containers 111 and 112. The integrity verification performed by security engine 104 is based on information provided to security engine 104 by the host-internal portion of the runtime protection mechanism. In an alternative example, security engine 104 may be executed within the computer 102 to be protected.

[0029] In some examples, security engine 104 may run within trusted computer system 140. A “trusted” computer system can refer to a computer system (including one or more computers) that has security mechanisms in place to protect it from intrusion or attack. For example, trusted computing system 140 may run within a secure network.

[0030] Trusted computing system 140 is coupled to the computer 102 (or multiple computers) to be protected via network 142. Network 142 may include a local area network (LAN), a wide area network (WAN), or another type of network. In other examples, security engine 104 may run in a virtual computer (such as a VM).

[0031] In some examples, computer 102 also includes container engine 130, which includes machine-readable instructions executable in user space 108. Container engine 130 supports the use of containers 111, 112. In some examples, container engine 130 may include any one or a combination of the following: containerd daemon, Docker container engine, CRI-O container engine, RKT container engine, LXD container engine, etc. Container engine 130 receives input (e.g., from a user via a user interface provided by container engine 130) related to building container images and starting or managing containers based on container images. A “container image” may refer to program code that starts a container at runtime and one or more programs that can be executed within the container. Container engine 130 may load container images (e.g., from a repository on the computer or at a remote location such as the cloud, web service, etc.) to create, construct, or start corresponding containers.

[0032] In some examples, container engine 130 can interact with container runtime daemon 132 to manage containers. Container runtime daemon 132 can be part of container engine 130 or separate from it. Container runtime daemon 132 can interact with OS kernel 124 to create, start, stop, and destroy containers. Examples of container runtime daemons include the containerd daemon, the dockerd daemon, etc. Although referred to as a "daemon" (i.e., a background process), in other examples, the container runtime can be implemented as a foreground process.

[0033] In some examples, a container orchestrator such as Kubernetes (not shown) can be used to control how and where containers run across a cluster of compute nodes. A "compute node" can refer to a physical computer or VM, such as computer 102. The container orchestrator can schedule the execution of containers on compute nodes based on available compute resources and the resource requirements of the containers. A Kubernetes cluster can include one or more control nodes and multiple compute nodes (also called "worker nodes") on which containers are deployed. The control node executes the container orchestrator. In other examples, a container orchestrator such as Kubernetes is not used.

[0034] In the example where computer 102 includes a VM instead of a container as a virtual computing environment, containers 111 and 112 can be replaced with VMs, and container engine 130 can be replaced with a hypervisor or VMM. Furthermore, the VM will run the corresponding guest OS. In a further example, containers 111 and 112 will run within the VM.

[0035] During the runtime of a container (e.g., 111 or 112), a program running within the container may issue a call to enable a program file 150 stored in storage medium 152. As described above, a program file can refer to a file containing program code (script, source code, or executable code), data, and / or a configuration file containing configuration information for the program, and / or any other type of object or collection of objects that affects how the program executes. "File" can refer to any type of object containing any of the foregoing.

[0036] Further reference below Figure 2 This is a message flow diagram illustrating the tasks of containers 111 and 112 and the kernel space runtime protection module 126. Note that... Figure 2The tasks can be executed in a different order than described, and at least some of the tasks can be executed concurrently. As used herein, "call" can generally refer to a command issued by a program during program execution within a container (e.g., a system call when OS106 is Linux), where said command invokes program file 150. "Invoke" program file can refer to startup program code for execution and / or access to data or configuration files, etc. Figure 2 In the example, the program in container 111 issues (at 252) call 1, followed by call 2. Calls 1 and 2 are intercepted by kernel space runtime protection module 126 (at 254), which updates (at 256) the container 1 log 202 for container 111. More specifically, in response to intercepting calls 1 and 2 from container 111, kernel space runtime protection module 126 adds a first log entry 211 for call 1 to log 202 and a second log entry 212 for call 2 to log 202. Kernel space runtime protection module 126 also updates (at 270) the header log entry 241 in the header log 206 (discussed further below).

[0037] In some examples, not all calls to program files are intercepted by the kernel space runtime protection module 126. Instead, the kernel space runtime protection module 126 can intercept calls to program files based on a monitoring policy at the kernel space runtime protection module 126. The monitoring policy can specify the type of program file call to be intercepted. For example, the monitoring policy can specify to intercept calls to executable program files but not calls to access data. As another example, the monitoring policy can specify to intercept calls to open configuration files but not calls to other types of program files.

[0038] Based on some examples in this disclosure, monitoring policies can be defined when building the runtime protection mechanism. In some examples, subsequent modifications to the monitoring policy are not allowed (after the runtime protection mechanism is built). In other examples, the monitoring policy can be modified dynamically during the operation of the runtime protection mechanism.

[0039] As used herein, "log" can refer to any data record used to store information related to calls made by a program within the container. Additionally, "updating" the log can refer to creating a log (if the log did not previously exist) or adding a log entry to the log. The kernel space runtime protection module 126 is able to use the functionality of the OS kernel 124 and intercept calls by interacting with the container runtime daemon 132.

[0040] The first log entry 211 of log 202 includes a checksum CK1 calculated based on the program file enabled by call 1, and the command of call 1 (command 1). The second log entry 212 of log 202 includes a checksum CK2 calculated based on the program file enabled by call 2, and the command of call 2 (command 2). In some examples, the checksum is a hash value generated by applying a hash function (e.g., a cryptographic hash function) to at least a portion of the program file. Examples of hash functions may include the Secure Hash Algorithm (SHA)-1 function, the SHA-2 function, the SHA-3 function, etc. In other examples, the checksum may be a value (e.g., a numeric value, an alphanumeric value, etc.) generated based on applying different functions to at least a portion of the program file.

[0041] although Figure 2 A specific example of a log entry in the container log is shown, but in other examples, different information may be stored in the container log. The kernel space runtime protection module 126 stores container 1 log 202 in memory 154 of computer 102. Figure 1 ).

[0042] like Figure 2 As further shown, the program in container 112 issues (at 258) calls 3, 4, and 5, which are intercepted by the kernel space runtime protection module 126 (at 260). In response to the interception of calls 3, 4, and 5, the kernel space runtime protection module 126 updates (at 262) the container 2 log 204 for container 112, wherein the log has corresponding log entries 231, 232, and 233 for calls 3, 4, and 5. Each log entry in log 204 contains a corresponding checksum and command. The kernel space runtime protection module 126 also updates (at 270) the header log entry 242 in the header log 206.

[0043] After calls 1 and 2 are issued from container 111, the program in container 111 issues (at 264) call 6, which is intercepted (at 266) by kernel space runtime protection module 126. In response to intercepting call 6, kernel space runtime protection module 126 updates container 1 log 202 for container 111 (at 268) by adding another log entry 213 corresponding to call 6. Kernel space runtime protection module 126 stores container 2 log 204 in memory 154 of computer 102. Figure 1 The kernel space runtime protection module 126 also updates (at 270) the header log entry 241 in the header log 206 (by recalculating the log checksum).

[0044] In some examples, as described above, the kernel space runtime protection module 126 can update (270) the header log 206, which contains header log entries 241 and 242 corresponding to the respective containers (e.g., 111 and 112). In some examples, each header log entry includes the following: a container identifier (ID), i.e., the identifier of the corresponding container; a log checksum calculated based on applying a function (e.g., a cryptographic hash function, etc.) to at least a portion of the corresponding log of the corresponding container; and a container image ID, i.e., the identifier of the container image from which the corresponding container is enabled.

[0045] exist Figure 2 In the example, header log entry 241 contains the container ID (CT1) of container 111, the log checksum (A) obtained based on the container 1 log 202 after the update performed in response to call 6 (at 268), and the container image ID (IM1) as an identifier of the container image of container 111. Note that header log entry 241 is updated after each update of container 1 log 202. Therefore, when container 1 log 202 is updated (at 256), the first update of header log entry 241 is performed (which produces a log checksum different from A). Then, when container 1 log 202 is updated again (at 268), the second update of header log entry 241 is performed (which produces log checksum A). Similarly, header log entry 242 contains the container ID (CT2) of container 112, the log checksum (B) obtained based on the container 2 log 204 after the update (at 262), and the container image ID (IM2) of the container image of container 112. For example, the container image may be stored in... Figure 1 A portion of the program file 150 in the storage medium 152.

[0046] The kernel space runtime protection module 126 stores the header log 206 in the memory 154 of the computer 102. Figure 1 ).although Figure 2 A specific example of a header log entry in header log 206 is shown, but in other examples, different information may be stored in the header log.

[0047] Logs 202, 204, and 206 include contextual information used to verify program file enabling, as discussed further below. Figure 1In the examples, the context information for logs 202, 204, and 206 includes a checksum associated with the corresponding command of the call made by the container, the container ID, a log checksum derived from the container logs, and a container image ID of the container image. In further examples, the context information in the logs may include additional or alternative information, such as tags indicating the program file type, the container's namespace and / or other metadata, computing environment information for the physical or virtual computing environment, program file attribute information, etc.

[0048] The environment information of a virtual computing environment can include information about the pods containing containers (in the example using Kubernetes), the type of virtualization used (e.g., Kubernetes, Docker, etc.), and hypervisor information. The environment information of a physical computing environment can include compute node information, resource information within the compute nodes, and information about the cluster, which includes some compute nodes. Program file attribute information can include program file attributes such as file size, timestamp, owner, permissions, path, and type.

[0049] Namespaces extract system resources (e.g., resources of computer 102) and allow system resources to appear as instances of system resources to processes (e.g., containers) belonging to said namespace, wherein instances of system resources are isolated from processes that do not belong to the namespace. Namespaces enable process isolation to implement container-based virtualization.

[0050] The host-side portion of the runtime protection mechanism can send logs 202, 204, and 206 (along with other information discussed further below) containing a proof request to security engine 104 to perform verification of the program file's enablement. A "proof request" can refer to a request to verify the enablement of a program file (or multiple program files) in a requester (e.g., computer 102). Two verifications are performed. First, verification of the proof request is performed, such as verifying the source of the proof request by checking the integrity of the proof request information using any one or a combination of the following: PCR quote (discussed below), key, random number, checksum, etc. Second, verification of the measurement results (checksum) included in the container and header logs is performed. In response to the proof request, security engine 104 can provide computer 102 with notification of whether the verification was successful and may include information regarding enforcement actions to be taken. Enforcement actions can include any one or a combination of the following: allowing the program file to enable upon successful verification, preventing the execution of program file enablement upon unsuccessful verification, providing an alert upon unsuccessful verification, etc.

[0051] like Figure 1As further shown, the security engine 104 can access reference information 160 stored in a repository 162 of the trusted computer system 140. The repository 162 can be in the form of a table, database, etc. The reference information 160 can be compared with information containing a verification request received by the security engine 104 from the host internals of a runtime protection mechanism to determine whether program file enabling can be verified. Verification of program file enabling can use a policy contained in policy information 164, which can be stored in the repository 162. Policy information 164 includes context-specific policies; in other words, different policies are applied in different contexts based on context information accompanying the verification request. The policies can specify enforcement measures based on verification of program file enabling.

[0052] Reference information 160 is created by security engine 104 or another entity (which may be a person, program, or machine). Reference information may include a reference checksum calculated based on a program file. Security engine 104 compares the reference checksum with a checksum contained in a log (e.g., 202, 204, 206) accompanying a proof request from the host machine's internal components of the runtime protection mechanism. Note that the checksum in the log is compared with that of the host machine (e.g., [missing information]). Figure 1 In section 102), the runtime checksum associated with the program file enabled during container runtime is used. For example, if the runtime checksum provided with the verification request does not match the corresponding reference checksum, it can indicate that the verification failed due to program file corruption. The above assumes that the reference checksum is used for allowed program files.

[0053] In a further example, a reference checksum can be provided for disallowed program files (e.g., those identified in a blacklist), which are program files known to be corrupted or contain malware. In such a further example, if the checksum provided with the proof request matches the reference checksum, it indicates that the corrupted program file has been enabled.

[0054] In some examples, the context information accompanying the proof request may also include a security processor protection value to indicate that other context information (such as logs) is valid (in other words, the context information itself is not corrupted). In some examples, the security processor protection value may be part of a platform configuration register (PCR) reference value. Figure 1As shown, TPM 156 includes a set of PCRs 158. A PCR is a storage element that stores the output of a checksum computation (such as the output of a cryptographic hash function). The PCR acts as an accumulator. When the value of a PCR is updated (expanded), the new PCR value depends on both the new computed value (the new computed checksum) and the existing values ​​(existing computed checksums) present in the PCR, ensuring that once a value is stored in the PCR, its value cannot be forged. For example, a new PCR value is obtained by applying a function (e.g., a hash function) to a set of existing PCR values ​​and the new computed value. Such an operation refers to expanding the existing PCR values ​​in the PCR with the new computed value.

[0055] The “PCR reference value” is a PCR value written using an electronic signature by TPM 156 (such as the PCR value in PCR 158). The PCR reference value (or more generally, the security processor protection value) provided to the security engine 104 from the host internal part of the runtime protection mechanism along with the proof request can be part of a series of contextual information used by the security engine 104 when verifying the program file.

[0056] Figures 3A to 3B A message flow diagram depicts the process of tasks comprising the following components: kernel space runtime protection module 126, user space runtime protection module 128, container runtime daemon 132, and security engine 104. Note that in other examples, Figures 3A to 3B The order of tasks can be changed, or Figures 3A to 3B Some tasks can be omitted or replaced with other tasks, or additional tasks can be included in further examples.

[0057] Security engine 104 stores reference information 160 and policy information 164 (at 302) in repository 162. Figure 1 Reference information 160 (including information discussed above) may be created by security engine 104 or another entity. Policy information 164 may be created by another entity and provided to security engine 104. Policies in policy information 164 may be used when determining whether to allow program file activation and whether to enforce program file activation.

[0058] The kernel space runtime protection module 126 monitors (at 304) container events, such as events related to the calling program file and events related to attempts to modify logs (e.g., logs 202, 204, 206). The kernel space runtime protection module 126 can check to prevent any modification to the logs unless the modification is performed by the kernel space runtime protection module 126 or another authorized entity.

[0059] Kernel space runtime protection module 126 also intercepts (at 306) calls to program files. Because kernel space runtime protection module 126 interacts with container runtime daemon 132 to intercept calls to program files, it has the container ID of the container from which the call originated. Kernel space runtime protection module 126 sends (at 308) an inquiry to obtain additional context information about the container identified by its container ID. The inquiry may include the container ID. Kernel space runtime protection module 126 may forward the inquiry to user space runtime protection module 128, which in turn forwards the inquiry to container runtime daemon 132.

[0060] In response to an inquiry for the container ID, the container runtime daemon 132 sends (at 310) a response containing context information about the container, including the container image ID of the container's container image, and other context information as further listed above. The response is sent to the user-space runtime protection module 128, which forwards the response to the kernel-space runtime protection module 126.

[0061] Based on the response from the container runtime daemon 132, the kernel space runtime protection module 126 is able to record (at 312) the association of each enabled program file (e.g., represented by the name and path of the program file) with context information such as the container ID, the container image ID, and additional attributes such as a label indicating the program file type, the container's namespace, computing environment information of the physical or virtual computing environment, program file attribute information, etc.

[0062] Kernel space runtime protection module 126 calculates a runtime checksum (at 314) based on each enabled program file. For each call from a container, kernel space runtime protection module 126 updates the container log (at 316) for the container by adding a log entry corresponding to the program file to the container log (e.g., 202 or 204). Log entries may include any or some combination of the context information discussed above. If there are calls from multiple containers, kernel space runtime protection module 126 updates multiple container logs for multiple containers. In other examples, container logs may include log entries for multiple containers within a defined partition (examples of partitions are further discussed above). Kernel space runtime protection module 126 also updates (at 316) the corresponding header log entry(s) of header log 206.

[0063] In TPM 156, the kernel space runtime protection module 126 anchors the checksum set included in the log (at 318) to PCR 158. More specifically, in some examples, the header log (e.g., Figure 2 The checksum set included in 206) is anchored to PCR 158. For example, in Figure 2 In the header log 206, header log entry 241 contains a checksum (A) obtained based on container 1 log 202, and header log entry 242 contains a checksum (B) obtained based on container 2 log 204. The checksum calculated based on header log 206 (referred to as the "header log checksum") can be used to expand the value in PCR 158.

[0064] Anchoring the set of checksums included in the header log to PCR 158 means extending PCR 158 with a header log checksum calculated based on the header log, and generating a digital signature for the header log checksum when it is obtained from PCR 158, so as to allow verification that the header log has not been corrupted and its origin can be determined.

[0065] For performance and scalability reasons, PCR can be used to anchor checksums for multiple header log entries. More generally, kernel-space runtime protection module 126 can correlate security processor protection values ​​with checksums in logs (header logs and / or container logs) to allow detection of corrupted logs.

[0066] In response to the triggering event, user-space runtime protection module 128 obtains the PCR reference value from TPM 156 (at 320) by requesting the PCR reference value from kernel-space runtime protection module 126, and obtains the associated logs (e.g., 202, 204, and 206) from memory 154. In some examples, the triggering event may include time-based events based on the elapsed time (e.g., timer expiration), events corresponding to multiple detected calls to the program file, etc. User-space runtime protection module 128 sends the PCR reference value and associated logs along with the proof request (at 322) to security engine 104.

[0067] Security engine 104 uses the PCR reference value to verify the integrity of header log 206 (at 324) (i.e., to ensure that header log 206 is not corrupted). Security engine 104 also uses log checksums in one or more header log entries to verify the integrity of the container log. Assuming header log 206 is verified, security engine 104 compares the runtime checksum of the program file in the container log (e.g., 202 and 204) with the reference checksum in reference information 160 (assuming reference information 160 contains the checksum of the program file) (at 326).

[0068] In some examples, security engine 104 determines whether an entry for Fx exists in reference information 160 for each program file (Fx), or in another example, it determines whether an entry for Fx exists in reference information 160 and whether the context (e.g., which container issued the enablement for Fx) is associated with the enablement of Fx. If the entry exists, a reference checksum for Fx can be obtained from the entry in reference information 160 and compared with the corresponding runtime checksum in the container log.

[0069] Security Engine 104 also applies a context-based policy (at 328) enabled for each program file. Figure 1 The policy information 164 includes multiple policies that can be applied to different environments. For example, a first policy may be applied to a first container image, a second policy to a second container image, and so on. For instance, if a container 111 launched from the first container image enables a specific program file, the first policy will be applied. On the other hand, if a container 112 launched from the second container image enables the same specific file, a different second policy will be applied. The first policy may specify that enabling a specific program file from container 111 is allowed if the runtime checksum of the specific program file matches the corresponding reference checksum, but is not allowed if the checksum does not match. The second policy may specify that enabling a specific program file from container 112 will be blocked (when possible) regardless of whether the checksum matches, and a signal will be issued as a security violation alert. In other examples, different policies may be applied in other types of contexts, such as different clusters, different host computers, different tenants, different times or dates, etc.

[0070] In some cases, reference information 160 may not include an entry for Fx (or a combination of Fx and the context in which Fx is enabled). In the latter case, the checksum comparison can be skipped, and the security engine can apply (at 326) a policy for unregistered or unknown program files. The policy can specify what enforcement actions to take for the enabling of unregistered or unknown Fx.

[0071] Based on the applied policy, security engine 104 sends (at 330) a proof notification in response to the proof request sent at 322. The proof notification may instruct the program file to enable, block, or instruct another enforcement measure.

[0072] In some examples, security engine 104 may log (at position 332) information associated with the integrity checks of each program file in the audit log. For example, security engine 104 may log any one or a combination of the following in the audit log: program file information, program file checksum, applied policies, timestamps, location information regarding where the program file is enabled, etc. The audit log can be used for analysis and profiling (such as identifying operational risks, learning the behavior of entities in a system), for training and inference in artificial intelligence or machine learning systems, etc.

[0073] Figure 4 This is a message flow diagram of the process of a task that includes the following components: user-space runtime protection module 128, kernel-space runtime protection module 126, TPM 156, and security engine 104. The task involves... Figures 3A to 3B Tasks 320, 322, 324, and 326 in the example. Note that in other examples, Figure 4 The order of tasks can be changed, or Figure 4 Some tasks can be omitted or replaced with other tasks, or additional tasks can be included in further examples.

[0074] In response to (the above combined) Figures 3A to 3B The event discussed triggers a request from user-space runtime protection module 128 to kernel-space runtime protection module 126 (at 402) to read header log 206. In response to this request, kernel-space runtime protection module 126 sends a runtime protection (RP) PCR read request to TPM 156 (at 404) to read the PCR associated with the runtime protection mechanism (e.g., ...). Figure 1 (158 in the middle). Figure 4 In the example, assume that the existing value of PCR 158 is "123" (this value will be referred to as the "initial PCR value"). In response, TPM 156 sends the initial PCR value ("123") to kernel space runtime protection module 126 (at 406).

[0075] exist Figure 4 In the example, kernel space runtime protection module 126 updates header log 206 (at 408) with initial PCR value entry 410 containing the initial PCR value (“123”). Note that header log entries corresponding to updates to the respective container logs are also updated for header log 206 (e.g., 241 and 242). Kernel space runtime protection module 126 calculates (at 412) a checksum (e.g., a hash value) based on the updated contents of header log 206. In the example, the checksum of header log 206 is “C”.

[0076] Kernel space runtime protection module 126 expands PCR 158 (at 414) with the "C" value from header log 206. In response to the expansion operation initiated by kernel space runtime protection module 126, TPM 156 expands PCR 158 (at 416) with the "C" value to produce an updated PCR value "456", which is stored in PCR 158. In some examples, although not shown, PCR 158 may also be expanded using a checksum from the container log. In other examples, PCR 158 is not expanded using a checksum from the container log. The updated PCR value is then added to header log 206.

[0077] TPM 156 sends the updated PCR value (“456”) to kernel space runtime protection module 126 (at 418). In response, kernel space runtime protection module 126 sends a header log 206 containing the current value of the PCR to user space runtime protection module 128 (at 420). In this example, the current value of the PCR is “456”.

[0078] In response to receiving header log 206, user-space runtime protection module 128 sends a read request (at 422) to kernel-space runtime protection module 126 to read the container log (which may include, for example, 202, 204) at kernel-space runtime protection module 126. In response to the read request, kernel-space runtime protection module 126 sends the container log (at 424) to user-space runtime protection module 128.

[0079] Then, the userspace runtime protection module 128 sends a PCR reference value request (at 426) to the TPM 156. In response, the TPM 156 returns a PCR reference value (at 428) that includes a digitally signed version of the current PCR value (“456”).

[0080] User-space runtime protection module 128 sends a verification request (at 430) to security engine 104. The verification request may include PCR reference values, as well as header logs and container logs.

[0081] In response to the proof request, security engine 104 performs a PCR replay (at 432), which includes calculating a checksum on header log 206 to obtain a header log checksum (e.g., "C"), extracting an initial PCR value ("123") from the initial PCR value entry 410 of header log 206, and expanding the initial PCR value with "C" to calculate an updated PCR value "456". Security engine 104 then decodes the PCR reference value to obtain the PCR value of the PCR reference value ("456") and compares the PCR value of the PCR reference value with the calculated updated PCR value. If the PCR values ​​match, it indicates that the header log 206 received at security engine 104 is not corrupted.

[0082] Security engine 104 can further calculate the checksums received along with the proof request on container logs 202 and 204, and compare the calculated checksums of container logs 202 and 204 with checksums "A" and "B" in header log entries 241 and 242, respectively. If the checksums of container logs 202 and 204 match checksums "A" and "B" in header log entries 241 and 242, respectively, the integrity of container logs 202 and 204 is verified.

[0083] Figure 5 This is a block diagram of a non-transitory machine-readable or computer-readable storage medium 500 storing machine-readable instructions that, when executed, cause a system (e.g., a computer or multiple computers) to perform corresponding tasks. Machine-readable instructions include those that execute during the runtime of a virtual computing environment (such as a container, VM, etc.).

[0084] Machine-readable instructions include program file call interception instructions 502 for intercepting calls to program files that enable program file execution in a virtual computing environment. In some examples, the calls can be intercepted by a kernel space entity, such as kernel space runtime protection module 126. In some examples, the interception can be based on a monitoring policy that specifies the type of program file call being intercepted.

[0085] Machine-readable instructions include context acquisition instruction 504 for obtaining context information about a virtual computing environment for a program file before enabling the program file in response to a call. In some examples, the context information includes an identifier of the program code image of the virtual computing environment (e.g., a container image). The context information may also include an identifier of the virtual computing environment (e.g., a container identifier), as well as other context information.

[0086] Machine-readable instructions include measurement calculation instructions 506 for calculating measurement values ​​based on the program file. In some examples, the measurement value is a checksum, such as a password hash value.

[0087] Machine-readable instructions include integrity check instructions 508 for providing measurement values ​​and context information of the virtual computing environment to the integrity checker to perform context-specific verification of the program file. In some examples, context-specific verification of the program file employs a strategy based on identifiers and / or other context information, such as information about the execution environment of the virtual computing environment (such as any environment information of the virtual computing environment further mentioned above), program file attribute information, etc.

[0088] In some examples, a first entity in kernel space (e.g., kernel space runtime protection module 126) sends a query for an identifier of a program code image to a second entity in user space (e.g., user space runtime protection module 128). The first entity in kernel space receives the identifier of the program code image from the second entity in user space.

[0089] In some examples, machine-readable instructions store the measured values ​​and the commands corresponding to the calls to enable program files in a record (e.g., a container log, such as 202 or 204). Machine-readable instructions may calculate a record checksum based on a record containing checksums of multiple program files called from the virtual computing environment, and include the record checksum in an additional record (e.g., a header log, such as 206) that associates the record checksum with an identifier of the program code image.

[0090] In some examples, machine-readable instructions associate measurements with registers in the security processor. This could involve anchoring the measurement using the TPM's PCR (which can be part of a set of measurements). The register value, along with the measurement, can be sent to an integrity checker to perform context-specific verification of the program file.

[0091] In some examples, machine-readable instructions add measurements to records (e.g., container logs). In some examples, records can be associated with virtual computing environments individually. In other examples, a record is an aggregate record containing measurements and identifiers of program code images of multiple virtual computing environments that are part of a specified partition (such as a pod, a given cluster of compute nodes, a partition of a container running a given application, a partition of a container started by a given requester (e.g., a tenant), etc.).

[0092] Figure 6 This is a block diagram of a computer 600 based on some examples. For example, computer 600 may correspond to... Figure 1 Computer 102. Computer 600 includes a security processor 602. For example, the security processor 602 may be a TPM.

[0093] Computer 600 includes virtual computing environment 604. Virtual computing environment 604 can be a container, VM, etc.

[0094] The computer 600 also includes a hardware processor 606 (or multiple hardware processors). The hardware processor may include a microprocessor, the core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit.

[0095] The computer 600 also includes a storage medium 608 that stores runtime protected instructions that can be executed on the hardware processor 606 to perform various tasks. Machine-readable instructions executable on the hardware processor may refer to instructions that can be executed on a single hardware processor or instructions that can be executed on multiple hardware processors.

[0096] Runtime protection instructions are executed during the runtime of the virtual computing environment 604. The runtime protection instructions include a program file call interception instruction 610 for intercepting calls to program files that enable program file execution related to the virtual computing environment 604.

[0097] Runtime protection instructions include a context information acquisition instruction 612 for obtaining context information about the virtual computing environment for the program file before enabling the program file in response to a call. The context information may include an identifier of the program code image of the virtual computing environment, an identifier of the virtual computing environment, and / or other context information.

[0098] Runtime protection instructions include a checksum calculation instruction 614 for calculating a checksum based on a program file. For example, the checksum calculation instruction 614 can apply a cryptographic hash function to the program file to obtain a hash value as the checksum.

[0099] Runtime protection instructions include security processor association instructions 616 for associating checksums with protection values ​​of the security processor. For example, the checksum can be anchored to the PCR of the TPM. More specifically, this anchoring can be based on the checksum of the header log anchored with the PCR.

[0100] Runtime protection instructions include integrity check instructions 618 for providing checksums and context information of the virtual computing environment to the integrity checker to perform context-specific verification of the program file before enabling the program file. Enabling the program file may include executing the program file, accessing the program file (e.g., opening), etc.

[0101] Figure 7This is a flowchart of process 700 based on some examples. Process 700 includes performing the following tasks during the runtime of the container. Process 700 includes intercepting (at 702) calls to enable program files related to the execution of programs within the container, according to a monitoring policy. The monitoring policy specifies that calls to program files of a first type should be intercepted, while calls to different second types of program files should not be intercepted. For example, the runtime protection system may include kernel space runtime protection module 126 and user space runtime protection module 128.

[0102] Process 700 includes obtaining (at 704) context information about the virtual computing environment for the program file by the runtime protection system before enabling the program file in response to a call. The context information includes an identifier for the program code image of the virtual computing environment, as well as other context information.

[0103] Process 700 includes a checksum calculated (at 706) by the runtime protection system based on the program file. For example, the checksum may include a password hash.

[0104] Process 700 includes the runtime protection system associating the checksum with the protection value of the security processor (at 708). For example, this association may include a PCR that anchors the log to the TPM.

[0105] Process 700 includes sending the checksum and container context information from the runtime protection system (at 710) to the integrity checker to perform context-specific verification of the program file before enabling the program file.

[0106] Storage media (e.g., Figure 5 The 500 in the text can include any one or a combination of the following: semiconductor memory devices such as DRAM or SRAM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; disks such as fixed disks, floppy disks, and removable disks; another magnetic medium, including magnetic tape; optical media such as optical discs (CDs) or digital video discs (DVDs); or another type of storage device. Note that the instructions discussed above may be provided on a single computer-readable or machine-readable storage medium, or alternatively, on multiple computer-readable or machine-readable storage media distributed across a large system having potentially multiple nodes. Such one or more computer-readable or machine-readable storage media are considered part of an article (or article of manufacture). An article of manufacture can refer to any single or multiple manufactured components. One or more storage media may be located in a machine that executes the machine-readable instructions or at a remote site from which the machine-readable instructions can be downloaded via a network for execution.

[0107] In this disclosure, unless the context clearly indicates otherwise, the terms “a,” “an,” or “the” are intended to include the plural form as well. Similarly, when used in this disclosure, the terms “includes / including / comprises / comprising” or “have / having” indicate the presence of the said element but do not preclude the presence or addition of other elements.

[0108] In the foregoing description, numerous details have been set forth to facilitate understanding of the subject matter disclosed herein. However, embodiments may be practiced without some of these details. Other embodiments may include modifications and variations of the details discussed above. The appended claims are intended to cover such modifications and variations.

Claims

1. A non-transitory machine-readable storage medium, comprising instructions that, when executed, cause a system to perform the following operations: During the runtime of the virtual computing environment: Intercept calls to enable program files related to program execution in the virtual computing environment; Calculate the checksum based on the program file; Before enabling the program file in response to the call, context information of the virtual computing environment, a log containing the command that invoked the program file and a checksum calculated based on the program file, and an additional checksum based on the log containing the command and the checksum are obtained for the program file, wherein the context information includes an identifier of the program code image of the virtual computing environment. The system sends the context information to the integrity checker as part of the proof to perform the enabled context-specific verification of the program file, wherein the context information includes the identifier of the program code image, the log, and the additional checksum based on the log; as well as At the system, a response is received from the integrity checker, the response containing the result of the proof using the log and the additional checksum based on the log.

2. The non-transitory machine-readable storage medium as described in claim 1, wherein, The context information obtained from the program file also includes the identifier of the virtual computing environment.

3. The non-transitory machine-readable storage medium as described in claim 1, wherein, The context-specific verification of the program file employs a strategy based on identifiers from the program code image.

4. The non-transitory machine-readable storage medium as described in claim 3, wherein, The context information also includes information about the execution environment of the virtual computing environment, and the strategy used for the context-specific verification is also based on the execution environment information.

5. The non-transitory machine-readable storage medium as described in claim 1, wherein, The interception of the call was performed by a first entity in the kernel space of the system.

6. The non-transitory machine-readable storage medium as described in claim 5, wherein, When the instruction is executed, it causes the system to perform the following operations: Send a query for the identifier of the program code image from the first entity in the kernel space to the second entity in the user space; as well as The identifier of the program code image is received from the second entity in the user space at the first entity in the kernel space.

7. The non-transitory machine-readable storage medium as claimed in claim 1, wherein, When the instruction is executed, it causes the system to perform the following operations: The checksum and the command corresponding to the enabled call to the program file are stored together in the log, wherein the checksum stored in the log includes a password hash value calculated based on the program file; as well as The additional checksum is calculated based on the log containing the checksum and the command.

8. The non-transitory machine-readable storage medium as claimed in claim 1, wherein, The log contains checksums of multiple program files invoked from the virtual computing environment, and the instructions, when executed, cause the system to perform the following operations: The additional checksum is calculated by applying a cryptographic hash function to the log containing the checksums of the plurality of program files; and The additional checksum is included in a separate log that associates the additional checksum with the identifier of the program code image.

9. The non-transitory machine-readable storage medium of claim 8, wherein, When the instruction is executed, it causes the system to perform the following operations: Associate the additional logs with the registers of the security processor; and The value of the register, along with the additional log, is sent to the integrity checker to perform the context-specific verification of the program file.

10. The non-transitory machine-readable storage medium of claim 9, wherein, The security processor is a Trusted Platform Module (TPM), and the register is a Platform Configuration Register (PCR). The value of the register is based on an extension of the PCR using a checksum calculated based on the additional log, and the context-specific verification includes verifying the additional log using the value of the PCR of the TPM.

11. The non-transitory machine-readable storage medium of claim 10, wherein, The value of the PCR sent to the integrity checker is digitally signed by the security processor.

12. The non-transitory machine-readable storage medium of claim 1, wherein, The log includes aggregated records containing checksums and identifiers of program code images that are part of a specified partition.

13. The non-transitory machine-readable storage medium as claimed in claim 1, wherein, The virtual computing environment includes containers, and the identifier of the program code image in the context information is a container image identifier.

14. A computer, comprising: Security processor; Hardware processor; as well as The non-transitory storage medium includes runtime protection instructions that can be executed on the hardware processor to perform the following operations: During the runtime of the virtual computing environment in the computer: Intercept calls to enable program files related to program execution in the virtual computing environment; Calculate the checksum based on the program file; Before enabling the program file in response to the call, context information of the virtual computing environment, a log containing the command that invoked the program file and a checksum calculated based on the program file, and an additional checksum based on the log containing the command and the checksum are obtained for the program file, wherein the context information includes an identifier of the program code image of the virtual computing environment. The checksum and the additional checksum are associated with the protection value of the security processor; Before enabling the program file, the identifier, including the program code image, the log, and the additional checksum based on the log are sent to the integrity checker to perform context-specific verification of the program file; as well as At the computer, a response is received from the integrity checker, the response containing the result of the context-specific verification using the log and the additional checksum based on the log.

15. The computer of claim 14, wherein, The activation of the program file is selected from the following situations: executing the program file including program code, or accessing the program file.

16. The computer of claim 14, wherein, The runtime protection instructions can be executed on the hardware processor to perform the following operations: Include the additional checksum and the identifier of the program code image in a separate log; as well as The context information, including the log and the other logs, is provided to the integrity checker.

17. The computer of claim 14, wherein, The protection value includes a platform configuration register (PCR) reference value, which includes a digitally signed version of the PCR value in the PCR of the security processor.

18. A method for context-specific validation, comprising: During container runtime: The runtime protection system intercepts calls to enable program files related to program execution in the container according to a monitoring policy, wherein the monitoring policy specifies that calls to a first type of program file should be intercepted, while calls to a different second type of program file should not be intercepted. The runtime protection system calculates a checksum based on the program file; Before enabling the program file in response to the call, the runtime protection system obtains context information of the virtual computing environment for the program file, a log containing the command that calls the program file and a checksum calculated based on the program file, and an additional checksum based on the log containing the command and the checksum, wherein the context information includes an identifier of the program code image of the virtual computing environment. The runtime protection system associates the checksum with the protection value of the security processor; The context information, including the identifier of the program code image, the log, and the additional checksum based on the log, is sent from the runtime protection system to the integrity checker to perform context-specific verification of the program file; and At the runtime protection system, a response is received from the integrity checker, the response containing the result of the context-specific verification using the log and the additional checksum based on the log.

19. The method of claim 18, wherein, The checksum is a password hash value.

20. The method of claim 18, wherein, The protection value includes the Platform Configuration Register (PCR) reference value, which includes a digitally signed version of the PCR value in the Trusted Platform Module (TPM) PCR.

Images