Patent Description:
It is the object of the present invention to provide a method and system for enforcing an integrity policy for a container managed by an operating system.

Methods, systems, apparatuses, and computer-readable storage mediums are described herein directed to protecting containers from malicious activity.

For instance, in one implementation, the integrity of a containerized application is verified using a block device signature. A container deployed to a host system is signed with a single block device signature. The same block device signature signs all the blocks of the block device (i.e., the container), and therefore, signs all the files of the container is (e.g., application files, dependency files, etc.). The operating system of the host system implements an integrity policy to verify the integrity of the container when the container is loaded into memory and when program code (e.g., the application) of the container executes. During such events, the operating system verifies whether the block device signature is valid. If the block device signature is determined to be valid, the operating system enables the program code to successfully execute. Otherwise, the program code is prevented from being executed.

In another implementation, the integrity policy is updated based on auditing of the containerized application. For instance, a containerized application may be executed while the integrity policy is not enforced. The containerized application is profiled to determine whether certain operations that violate the integrity policy are legitimate or illegitimate. For operations that violate the integrity policy but are deemed legitimate, the integrity policy is updated to allow such operations so that such operations no longer violate the integrity policy.

Further features and advantages of embodiments, as well as the structure and operation of various embodiments, are described in detail below with reference to the accompanying drawings. It is noted that the methods and systems are not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.

The following detailed description discloses numerous example embodiments. The scope of the present patent application is not limited to the disclosed embodiments, but also encompasses combinations of the disclosed embodiments, as well as modifications to the disclosed embodiments.

Embodiments described herein are directed to verifying the integrity of a containerized application using a block device signature. For example, a container deployed to a host system is signed with a single block device signature. The same block device signature signs all the blocks of the block device (i.e., the container), and therefore, signs all the files of the container (e.g., application files, dependency files, etc.). The operating system of the host system implements an integrity policy to verify the integrity of the container when the container is loaded into memory and when program code (e.g., the application) of the container executes. During such events, the operating system verifies whether the block device signature is valid. If the block device signature is determined to be valid, the operating system enables the program code to successfully execute. Otherwise, the program code is prevented from being executed.

By doing so, certain program code or processes (e.g., malicious processes, such as viruses and malware) that are not properly signed are prevented from executing, thereby protecting the host system from such processes. Moreover, by using a single block-level signature for a container, the enforcement of the integrity policy is greatly simplified than compared with alternative solutions that require each file in a container to be individually signed.

Embodiments described herein also are directed to updating the integrity policy based on auditing of the containerized application. For instance, a containerized application may be executed while the integrity policy is not enforced. The containerized application is profiled to determine whether certain operations that violate the integrity policy are legitimate or illegitimate. For operations that violate the integrity policy but are deemed legitimate, the integrity policy is updated to allow such operations so that such operations no longer violate the integrity policy.

<FIG> shows a block diagram of a system <NUM> comprising a host system <NUM> for hosting and/or executing one or more containers 110A-110N, according to an example embodiment. Host system <NUM> may comprise a computing device, such as a stationary computing device or a mobile computing device. Examples of stationary computing devices include, but are not limited to, a desktop computer or PC (personal computer), a server, etc. Examples of mobile computing devices include, but are not limited to, a Microsoft® Surface® device, a personal digital assistant (PDA), a laptop computer, a notebook computer, a tablet computer such as an Apple iPad™, a netbook, a smart phone (such as an Apple iPhone, a phone implementing the Google® Android™ operating system, etc.), a wearable computing device (e.g., a head-mounted device including smart glasses such as Google® Glass™, a virtual headset such as Oculus Rift® by Oculus VR, LLC or HoloLens® by Microsoft Corporation, etc.). Host system <NUM> may also comprise a virtual machine executing on a stationary or mobile computing device. Host system <NUM> may be implemented into a cloud-based computing environment. For instance, host system <NUM> may comprise a network-accessible server (i.e., a node) of a network-accessible server set or a virtual machine executing thereon. The network-accessible server set may be colocated (e.g., housed in one or more nearby buildings with associated components such as backup power supplies, redundant data communications, environmental controls, etc.) to form a datacenter, or may be arranged in other manners. Accordingly, in an embodiment, the network-accessible server set may be a datacenter in a distributed collection of datacenters.

As shown in <FIG>, host system <NUM> may comprise an operating system <NUM>, container orchestrator <NUM>, a container engine <NUM> and one or more container(s) 110A-110N. Operating system <NUM> may manage one or more hardware components (e.g., processor(s), main memory, secondary storage device(s), etc.) and software executing in host system <NUM>. Example hardware components of host system <NUM> are described in detail below in reference to <FIG>. Operating system <NUM> may comprise one or more components that perform certain tasks relating to the execution of software (e.g., container orchestrator <NUM>, container engine <NUM>, and/or container(s) 110A-110N in host system <NUM>. Examples of operating system <NUM> include, but are not limited to, MICROSOFT® WINDOWS® Operating System (OS), published by Microsoft Corporation of Redmond, Washington, Apple macOS®, Google Android™, LINUX®, or other UNIX® variants. Each of container(s) 110A-110N, container engine <NUM>, container orchestrator <NUM>, operating system <NUM>, and policy enforcer <NUM> may be stored and/or executed within a memory (not shown) of host system <NUM>.

Container orchestrator <NUM> may be configured to automate deployment, scaling and availability of applications running in container(s) 110A-110N. For instance, in an embodiment in which host system <NUM> is implemented into a cloud-based computing environment, container orchestrator <NUM> may determine when to deploy container(s) 110A-110N to container engine <NUM> executing on a particular one or more nodes. Container orchestrator <NUM> may also manage other components executing in host system <NUM>, such as container engine <NUM>. Container orchestrator <NUM> may wrap container(s) that share the same computing resources and/or networks into a higher-level structure (e.g., pod <NUM>). For example, as shown in <FIG>, container(s) 110A-110N are wrapped into pod <NUM>. An example of container orchestrator <NUM> includes, but is not limited to, Kubernetes®, published by Google® Inc.

Container engine <NUM> may be configured host and/or execute containerized applications, such as container(s) 110A-110N, that are deployed thereto via container orchestrator <NUM>. Container(s) 110A-110N may be created based on corresponding container image(s) (or binary(ies)) 112A-112N, which are provided to host system <NUM>. Container image(s) 112A-112N may be provided to host system <NUM> by end-users that develop containerized applications and/or developers that develop containerized applications for end-users. In the latter case, the container image(s) may be stored in a code repository and may be accessible to end-users. An example of container engine <NUM> includes, but is not limited to Docker®, published by Docker®, Inc.

Each of container(s) 110A-110N is a standard unit of executable software that packages program code of an application and all its dependencies necessary for application execution so that the application runs quickly and reliably from one computing environment (e.g., host system <NUM>) to another. Examples of dependencies include, but are not limited to, system tools, system libraries and settings, runtimes, etc. Container image(s) 112A-112N are mapped into memory as corresponding container(s) 110A-110N at runtime when executed by container engine <NUM>. An application running in a container of container(s) 110A-110N is isolated from the rest of host system <NUM> and from other containers of container(s) 110A-110N. Container(s) 110A-110N share operating system <NUM> installed in host system <NUM> and execute as resource-isolated processes, ensuring quick, reliable, and consistent deployments, regardless of environment.

Each of container image(s) 112A-112N may be digitally signed by a signature <NUM> to confirm its author/publisher and guarantee that the code has not been altered or corrupted since was signed. For instance, each of container image(s) 112A-112N may be deployed with a signature file (shown as signature <NUM>) that comprises a block device signature. A block is a readable and/or writable data block. The data block has a fixed-size (e.g., <NUM> or multiples thereof). Devices that support reading and/or writing in fixed-size block are referred to as block devices (e.g., USB storage devices (e.g., thumb drives, external hard drives, etc.), hard disk drives, solid state drives, etc.). Each of container(s) 110A-110N also support the reading and/or writing in fixed-size blocks and may be referred to as virtual block devices.

To apply a block device signature (i.e., signature <NUM>) to a container image (e.g., container image 112A-112N, a hash tree signing mechanism may be utilized that applies a hash for every block comprised therein (e.g., an SHA256 hash). Each of the hash values are stored in a tree of pages. A change in a single child block in the tree results in a change of the top-level root hash. As such, only the top-level root hash must be trusted to verify the rest of the tree. A modification to any of the blocks would be equivalent to breaking the hash. Accordingly, a single signature <NUM> is associated with all the contents (or files) (i.e., the application and its dependencies) of a corresponding container of container(s) 110A-110N such that only a single signature <NUM> is required to verify the integrity of the corresponding container. In accordance with an embodiment, each of signatures <NUM> is a dm (device mapper)-verity or a fs (file system)-verity signature. Each of container(s) 110A-110N also comprises an unchangeable public key <NUM>, which is used to verify signature <NUM> and confirm that container(s) 110A-110N are protected and unchanged.

As further shown in <FIG>, operating system <NUM> may comprise a policy enforcer <NUM>. Policy enforcer <NUM> may be configured to verify the integrity of each of container(s) 110A-110N mapped into memory and determine whether each of container(s) 110A-110N complies with an integrity policy. For example, policy enforcer <NUM> may determine whether each of container(s) 110A-110B is associated with a signature file (i.e., signature <NUM>) that comprises a block-level signature. Signature <NUM> represents signature <NUM> that has been mapped into memory. If no such file or signature exists, policy enforcer <NUM> may prevent a container from executing. If such a file and signature exist, policy enforcer <NUM> may be configured to verify the integrity of each of container(s) 110A-110N by determining whether signature <NUM> is valid based on public key <NUM>. Public key <NUM> represents public key <NUM> that has been mapped into memory. For instance, policy enforcer <NUM> may calculate a hash of a container of container(s) 112A-112N, decrypt the corresponding signature <NUM> to obtain the top-level root hash using the corresponding public key <NUM> and compare the calculated hash value with the top-level root hash. If the hash values are the same, then policy enforcer <NUM> determines that the container has not been altered.

Policy enforcer <NUM> may be configured to perform the foregoing check at the time container image(s) 112A-112N are loaded into memory (e.g., when the file system for the corresponding container of container(s) 110A-110N is mounted for usage by operating system <NUM>). If the calculated hash matches the top-level root hash, then container(s) 110A-110N are monitored for the initiation of execution of the application and/or file access operations performed by the application for compliance with the integrity policy. If the hash values do not match, then container(s) 110A-110N are unloaded from memory (e.g., the file system is unmounted).

Policy enforcer <NUM> may also perform the foregoing integrity check when initiation of application execution (and/or processes of the application) and file access operations performed by the application are detected. For example, policy enforcer <NUM> may be configured to hook function calls performed by container(s) 110A-110N (and/or the application included therein) that initiate execution of code thereof and/or perform file access operations (e.g., read, write, open, etc.). An example of a function call that initiates execution of code includes, but is not limited to, is execve(). Upon hooking such a function, policy enforcer <NUM> calculates the hash of the container making the call and compares it to the top-level root hash of the container. If the calculated hash matches the top-level root hash, then policy enforcer <NUM> enables the function call to complete, thereby enabling execution of the application (or process thereof). If the hash values do not match, then the function call is not enabled to complete, thereby preventing execution of the application (or process thereof). When monitoring file access operations, policy enforcer <NUM> may hook function calls that perform file access operations (e.g., open()). Upon hooking such a function call, policy enforcer <NUM> calculates the hash of the file being accessed and compares it to the top-level root hash of the container. If the calculated hash matches the top-level root hash, then policy enforcer <NUM> enables the function call to complete, thereby enabling the file access operation to complete. If the hash values do not match, then the function call is not enabled to complete, thereby preventing the file access operation from occurring.

As further shown in <FIG>, each of container image(s) 112A-112N may further comprise an integrity policy <NUM>, and each of container(s) 110A-110N may further comprise an integrity policy <NUM>, which represents integrity policy <NUM> that has been mapped into memory. Integrity policy <NUM> and integrity policy <NUM> may specify rules that define the signature type to be used for signing the corresponding container (i.e., block device signatures) and/or legal file access operations. For example, the rules may specify a listing of directories and/or files of the corresponding container application's file system that may be opened, read and/or written to via file access operations of the container application. Policy enforcer <NUM> may implement the rules specified by integrity policy <NUM> to determine whether container(s) <NUM>10A-110N comply with integrity policy <NUM>. Policy enforcer <NUM> may determine that container(s) 110A-110N do not comply with integrity policy <NUM> if container(s) 110A-110N are not signed by the signature defined by integrity policy <NUM> and/or by detecting file access operations that do not conform with the file access operation rules of integrity policy <NUM>. Any file access operations that violate a rule of integrity policy <NUM> may be logged and/or blocked from being performed.

It is noted that while the foregoing techniques describe that container(s) 110A-110N are associated with a block device signature, it is noted that other components executing on host system <NUM> may also comprise a block device signature. For example, container orchestrator <NUM> and container engine <NUM> may each comprise a respective block device signature that is verified by policy enforcer <NUM> at the time such components are loaded into memory.

It is further noted that in certain scenarios, each of container image(s) 112A-112N and containers 110A-110N may not comprise a respective policy <NUM> and policy <NUM>. In such scenarios, policy enforcer <NUM> may maintain and/or enforce a single (and/or default) integrity policy (not shown) for each of container(s) 110A-110N. That is, the same integrity policy is enforced by policy enforcer <NUM> for all container(s) 110A-110N of host system <NUM>. Such a policy may be updated and/or refined based on an auditing of container(s) 110A-110N as will be described below with reference to Subsection B.

Accordingly, an integrity policy may be utilized to protect a host system utilized for container execution in many ways. <FIG> shows a flowchart <NUM> of a method for enforcing an integrity policy for a container managed by the operating system, according to an example embodiment. In an embodiment, flowchart <NUM> may be implemented by an operating system, such as by a policy enforcer <NUM> of operating system <NUM>, as shown in <FIG> is a block diagram of a host system <NUM> configured to enforce an integrity policy <NUM> for a container <NUM> managed by operating system <NUM>, according to an example embodiment. As shown in <FIG>, host system <NUM> includes operating system <NUM> and a pod <NUM>. Operating system <NUM> comprises policy enforcer <NUM>, and pod <NUM> may comprise one or more containers (e.g., container <NUM>). Container <NUM> comprises an application <NUM>, application dependencies <NUM>, a signature file <NUM>, a public key <NUM>, and integrity policy <NUM>. Host system <NUM>, operating system <NUM>, policy enforcer <NUM>, pod <NUM>, container <NUM>, signature file <NUM>, public key <NUM>, and integrity policy <NUM> are examples of host system <NUM>, operating system <NUM>, policy enforcer <NUM>, pod <NUM>, container <NUM>, signature file <NUM>, public key <NUM>, and integrity policy <NUM>, as described above with reference to <FIG>. As also shown in <FIG>, policy enforcer <NUM> comprises a signature checker <NUM>, a signature validator <NUM>, and a monitor <NUM>. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart <NUM> and host system <NUM> of <FIG>.

Flowchart <NUM> of <FIG> begins with step <NUM>. In step <NUM>, a determination is made as to whether a block device signature is associated with a container that packages an application and dependencies that enable the application to execute, the block device signature also associated with the application and the dependencies as a result of being associated with the container. If a determination is made that the block device signature is not associated with the container, then flowchart <NUM> continues to step <NUM>. Otherwise, flowchart <NUM> continues to step <NUM>. For instance, as shown in <FIG>, signature checker <NUM> may determine whether a block device signature (e.g., signature <NUM>) is associated with container <NUM> that packages application <NUM> and its dependencies <NUM>. For example, signature checker <NUM> may provide a request <NUM> to container <NUM>. Responsive to receiving request <NUM>, container <NUM> may provide a response <NUM> to signature checker <NUM> that comprises signature file <NUM>, public key <NUM> and/or integrity policy <NUM>. Signature checker <NUM> may determine whether signature file <NUM> includes a block device signature (in accordance with integrity policy <NUM>). If signature file <NUM> does not include a block device signature, if response <NUM> indicates that no signature file <NUM> exists, or if container <NUM> does not provide response <NUM>, signature checker <NUM> may determine that a block device signature is not associated with container <NUM>, and flowchart <NUM> continues to step <NUM>. If signature file <NUM> includes a block device signature, signature checker <NUM> may determine that signature file <NUM> includes a block device signature and provides signature file <NUM> and public key <NUM> to signature validator and provides integrity policy <NUM> to monitor <NUM>. Flowchart <NUM> then continues to step <NUM>.

In accordance with one or more embodiments, the block device signature is a hash tree-based signature. In accordance with one or more embodiments, the hash-tree signature comprises at least one of a dm-verity signature or an fs-verity signature. In other embodiments, other types of signatures may be used.

In step <NUM>, execution of the application of the container is prevented. For example, with reference to <FIG>, policy enforcer <NUM> prevents application <NUM> from executing, for example, by unloading container <NUM> from memory (i.e., memory of host system <NUM>).

In step <NUM>, a determination is made as to whether the block device signature is valid. In response to determining that the block device signature is invalid, flowchart <NUM> continues to step <NUM>. Otherwise, flowchart <NUM> continues to step <NUM>. For example, with reference to <FIG>, signature validator <NUM> determines whether the block device signature is valid. For example, signature validator <NUM> may calculate a hash of container <NUM>, decrypt signature of signature file <NUM> to obtain the top-level root hash using public key <NUM>, and compare the calculated hash value with the top-level root hash. If the hash values are the same, then signature validator <NUM> determines that the block device signature is valid and provides an indicator <NUM> to monitor <NUM> that indicates that the block device signature is valid. Flowchart <NUM> then continues to step <NUM>. Otherwise, flowchart <NUM> continues to step <NUM>. Additional details regarding determining whether a block-valid signature is valid is described below with reference to <FIG>.

In step <NUM>, initiation of execution of the application and file access operations performed by the application are monitored for compliance with the integrity policy. For example, with reference to <FIG>, responsive to receiving indicator <NUM>, monitor <NUM> may monitor initiation of execution of application <NUM> and file access operations performed by application <NUM> for compliance with integrity policy <NUM>.

In accordance with one or more embodiments, policy enforcer <NUM> may determine whether a block device signature is associated with container <NUM> at the time a file system of container <NUM> is mounted. For example, <FIG> shows a flowchart <NUM> of a method for determining whether a block device signature is associated with a container, according to an example embodiment. In an embodiment, flowchart <NUM> may be implemented by a policy enforcer <NUM>, as shown in <FIG> is a block diagram of a host system <NUM> configured to determine whether a block device signature is associated with a container <NUM>, according to an example embodiment. As shown in <FIG>, host system <NUM> includes an operating system <NUM>, a container engine <NUM>, and a pod <NUM>. Operating system <NUM> comprises policy enforcer <NUM>, and pod <NUM> may comprise one or more containers (e.g., container <NUM>). Container <NUM> comprises an application <NUM>, application dependencies <NUM>, signature file <NUM>, a public key <NUM>, and an integrity policy <NUM>. Host system <NUM>, operating system <NUM>, policy enforcer <NUM>, pod <NUM>, container <NUM>, signature file <NUM>, public key <NUM>, and integrity policy <NUM> are examples of host system <NUM>, operating system <NUM>, policy enforcer <NUM>, pod <NUM>, container <NUM>, signature file <NUM>, public key <NUM>, and integrity policy <NUM>, as described above with reference to <FIG>. Container engine <NUM> is an example of container engine <NUM>, as described above with reference to <FIG>. As also shown in <FIG>, policy enforcer <NUM> comprises a signature checker <NUM>, a signature validator <NUM>, and a monitor <NUM>, which are examples of signature checker <NUM>, signature validator <NUM>, and monitor <NUM>, as respectively described above with reference to <FIG>. As further shown in <FIG>, container engine <NUM> has mounted a file system <NUM>, which is utilized by application <NUM>. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart <NUM> and host system <NUM> of <FIG>.

Flowchart <NUM> of <FIG> begins with step <NUM>. In step <NUM>, a determination is made as to whether a mounted file system of the container that is utilized by the application is signed with the block device signature. If a determination is made that the mounted file system is not signed with the block device signature, then flowchart <NUM> continues to step <NUM>. Otherwise, flowchart <NUM> continues to step <NUM>. For instance, with reference to <FIG>, signature checker <NUM> may detect that file system <NUM> of container <NUM> has been mounted. For example, container engine <NUM> may provide an indicator <NUM> to signature checker <NUM> that notifies signature checker <NUM> that file system <NUM> has been mounted. Responsive to determining that file system <NUM> has been mounted, signature checker <NUM> may provide a request <NUM> to container <NUM>. Responsive to receiving request <NUM>, container <NUM> may provide a response <NUM> to signature checker <NUM> that comprises signature file <NUM>, public key <NUM> and/or integrity policy <NUM>. Signature checker <NUM> may analyze signature file <NUM> to determine whether it comprises a block device signature. If signature file <NUM> does not comprise a block device signature, flowchart <NUM> continues to step <NUM>. Otherwise, signature checker <NUM> provides signature file <NUM> and public key <NUM> to signature validator <NUM> and provides policy <NUM> to monitor <NUM>. Flowchart <NUM> then continues to step <NUM>.

At step <NUM>, the file system is unmounted, thereby preventing execution of the application. For example, with reference to <FIG>, signature checker <NUM> may provide a command to container engine <NUM> that causes container engine <NUM> to unmount file system <NUM>.

At step <NUM>, in response to determining that the mounted file system is signed with the block device signature and that the block device signature is valid, initiation of execution of the application and file access operations performed by the application are monitored for compliance with the integrity policy. For example, with reference to <FIG>, signature validator <NUM> may determine whether signature file <NUM> comprises a valid block device signature. For example, signature validator <NUM> may calculate a hash of file system <NUM>, decrypt signature of signature file <NUM> to obtain the top-level root hash using public key <NUM>, and compare the calculated hash value with the top-level root hash. If the hash values are the same, then signature validator <NUM> determines that the block device signature is valid. In response, signature validator <NUM> may provide an indicator <NUM> to monitor <NUM> to indicate that monitor <NUM> is to monitor container <NUM> for initiation of execution of application <NUM> and file access operations performed by application <NUM> for compliance with integrity policy <NUM>. If the hash values are different, policy enforcer <NUM> prevents application <NUM> from executing, for example, by providing a command to container engine <NUM> that causes container engine <NUM> to unmount file system <NUM>.

<FIG> shows a flowchart <NUM> of a method for determining whether an application is enabled to execute, according to an example embodiment. In an embodiment, flowchart <NUM> may be implemented by a policy enforcer <NUM>, as shown in <FIG> is a block diagram of a host system <NUM> configured to determine whether an application <NUM> is enabled to execute, according to an example embodiment. As shown in <FIG>, host system <NUM> includes an operating system <NUM>, a container engine <NUM>, and a pod <NUM>. Operating system <NUM> comprises a policy enforcer <NUM>, and pod <NUM> may comprise one or more containers (e.g., container <NUM>). Container <NUM> comprises application <NUM>, application dependencies <NUM>, signature file <NUM>, a public key <NUM>, and an integrity policy <NUM>. Host system <NUM>, operating system <NUM>, policy enforcer <NUM>, pod <NUM>, container <NUM>, signature file <NUM>, public key <NUM>, and integrity policy <NUM> are examples of host system <NUM>, operating system <NUM>, policy enforcer <NUM>, pod <NUM>, container <NUM>, signature file <NUM>, public key <NUM>, and integrity policy <NUM>, as described above with reference to <FIG>. Container engine <NUM> is an example of container engine <NUM>, as described above with reference to <FIG>. As also shown in <FIG>, policy enforcer <NUM> comprises a signature checker <NUM>, a signature validator <NUM>, and a monitor <NUM>, which are examples of signature checker <NUM>, signature validator <NUM>, and monitor <NUM>, as respectively described above with reference to <FIG>. As further shown in <FIG>, monitor <NUM> comprises an operation detector <NUM>. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart <NUM> and host system <NUM> of <FIG>.

Flowchart <NUM> of <FIG> begins with step <NUM>. In step <NUM>, initiation of execution of the application is detected. For example, operation detector <NUM> may detect initiation of execution of application <NUM>.

In accordance with one or more embodiments, initiation of execution of the application is detected by hooking a function call that causes the application to execute. For example, with reference to <FIG>, operation detector <NUM> may hook a function call <NUM> issued by container engine <NUM> that causes application <NUM> to execute. An example of such a function is the execve() function call, although the embodiments described herein are not so limited. Responsive to hooking function call <NUM>, monitor <NUM> may provide an indicator <NUM> to signature validator <NUM> to indicate that signature validation is required.

In step <NUM>, a determination is made as to whether the application is signed with a valid block device signature (i.e., the block device signature associated with container <NUM>). If a determination is made that the application is not signed with a valid block device signature, then flowchart <NUM> continues to step <NUM>. Otherwise, flowchart <NUM> continues to step <NUM>. For example, with reference to <FIG>, signature validator <NUM>, responsive to receiving indicator <NUM>, may calculate a hash of application <NUM>, decrypt signature of signature file <NUM> (which is an example of signature file <NUM>, as described a above with reference to <FIG>) to obtain the top-level root hash using public key <NUM> (which is an example of public key <NUM>, as described above with reference to <FIG>), and compare the calculated hash value with the top-level root hash. If the hash values are the same, then signature validator <NUM> determines that the block device signature of application <NUM> is valid, and flowchart <NUM> continues to step <NUM>. If the hash values are different, signature validator <NUM> determines that the block device signature of application <NUM> is invalid, and flowchart <NUM> continues to step <NUM>.

At step <NUM>, execution of the application is prevented. For example, with reference to <FIG>, operation detector <NUM> may prevent application <NUM> from executing by preventing function call <NUM> from completing.

At step <NUM>, execution of the application is enabled. For example, with reference to <FIG>, operation detector <NUM> may enable execution of application <NUM> by enabling function call <NUM> to complete.

<FIG> shows a flowchart <NUM> of a method for determining whether a file access operation from an application is authorized to complete, according to an example embodiment. In an embodiment, flowchart <NUM> may be implemented by a policy enforcer <NUM>, as shown in <FIG> is a block diagram of a host system <NUM> configured to determine whether a file access operation from an application <NUM> is authorized to complete, according to an example embodiment. As shown in <FIG>, host system <NUM> includes an operating system <NUM>, a container engine <NUM>, and a pod <NUM>. Operating system <NUM> comprises a policy enforcer <NUM>, and pod <NUM> may comprise one or more containers (e.g., container <NUM>). Container <NUM> comprises an application <NUM>, application dependencies <NUM>, signature file <NUM>, a public key <NUM>, and an integrity policy <NUM>. Host system <NUM>, operating system <NUM>, policy enforcer <NUM>, pod <NUM>, container <NUM>, signature file <NUM>, public key <NUM>, and integrity policy <NUM> are examples of host system <NUM>, operating system <NUM>, policy enforcer <NUM>, pod <NUM>, container <NUM>, signature file <NUM>, public key <NUM>, and integrity policy <NUM>, as described above with reference to <FIG>. Container engine <NUM> is an example of container engine <NUM>, as described above with reference to <FIG>. As also shown in <FIG>, policy enforcer <NUM> comprises a signature checker <NUM>, a signature validator <NUM>, and a monitor <NUM>, which are examples of signature checker <NUM>, signature validator <NUM>, and monitor <NUM>, as respectively described above with reference to <FIG>. As further shown in <FIG>, container engine <NUM> has mounted a file system <NUM>, which is utilized by application <NUM>, and monitor <NUM> comprises an operation detector <NUM>. File system <NUM> is an example of file system <NUM>, as described above with reference to <FIG>. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart <NUM> and host system <NUM> of <FIG>.

Flowchart <NUM> of <FIG> begins with step <NUM>. In step <NUM>, a file access operation with respect to a file of a mounted file system of the container is detected. For example, operation detector <NUM> may detect a file access operation <NUM> with respect to a file of mounted file system <NUM> of container <NUM> is detected.

In accordance with one or more embodiments, a file access operation is detected by hooking a function call that is configured to open the file. For example, with reference to <FIG>, operation detector <NUM> may hook file access operation <NUM>, which may be function call issued by container <NUM> that is configured to open a file of file system <NUM>. An example of such a function is the open() function call, although the embodiments described herein are not so limited. Responsive to hooking function call <NUM>, monitor <NUM> may provide an indicator <NUM> to signature validator <NUM> to indicate that signature validation is required.

In step <NUM>, a determination is made as to whether the file is signed with a valid block device signature (i.e., the block device signature associated with container <NUM>). If a determination is made that the application is not signed with a valid block device signature, then flowchart <NUM> continues to step <NUM>. Otherwise, flowchart <NUM> continues to step <NUM>. For example, with reference to <FIG>, signature validator <NUM>, responsive to receiving indicator <NUM> signature validator <NUM>, may calculate a hash of the file of file system <NUM>, decrypt signature of signature file <NUM> (which is an example of signature file <NUM>, as described a above with reference to <FIG>) to obtain the top-level root hash using public key <NUM> (which is an example of public key <NUM>, as described above with reference to <FIG>), and compare the calculated hash value with the top-level root hash. If the hash values are the same, then signature validator <NUM> determines that the block device signature of the file is valid, and flowchart <NUM> continues to step <NUM>. If the hash values are different, signature validator <NUM> determines that the block device signature of the file invalid and flowchart <NUM> continues to step <NUM>.

At step <NUM>, the file access operation is prevented. For example, with reference to <FIG>, operation detector <NUM> may prevent file access operation <NUM> from performed by preventing the corresponding function call from completing.

At step <NUM>, execution of the application is enabled. For example, with reference to <FIG>, operation detector <NUM> may enable file access operation <NUM> to be completed by enabling the corresponding function call to complete.

In certain scenarios, the policy specified by a container is not comprehensive or incomplete. For instance, the policy may be a default policy that is not specific to the application of the container. In such scenarios, legitimate code of the container's application may be prevented from performing certain operations (e.g., file access operations) due to such operations violating the policy. In accordance with an embodiment, the container is audited to determine whether the policy should be modified to properly grant certain operations and/or block other operations. The foregoing may be achieved by executing the application while the integrity policy is placed in an audit mode. During the audit mode, validation detection of the integrity policy is enabled, but enforcement of the integrity policy is disabled. By doing so, any policy violations caused by execution of the application are detected, but the operations are permitted to complete. The operations performed by the application that caused the violations are then analyzed to determine whether such operations are legitimate. If such operations are deemed legitimate, the integrity policy is updated to allow such operations during normal operation (i.e., when the policy is not in audit mode). If such operations are deemed illegitimate, then no changes are made to the integrity policy.

<FIG> shows a flowchart <NUM> of a method for updating an integrity policy, according to an example embodiment. In an embodiment, flowchart <NUM> may be implemented by a policy enforcer <NUM>, as shown in <FIG> is a block diagram of a host system <NUM> configured to update an integrity policy <NUM>, according to an example embodiment. As shown in <FIG>, host system <NUM> includes an operating system <NUM> and a pod <NUM>. Operating system <NUM> comprises a policy enforcer <NUM>, and pod <NUM> may comprise one or more containers (e.g., container <NUM>). Container <NUM> comprises an application <NUM>, application dependencies <NUM>, signature file <NUM>, a public key <NUM>, and integrity policy <NUM>. Host system <NUM>, operating system <NUM>, policy enforcer <NUM>, pod <NUM>, container <NUM>, signature file <NUM>, public key <NUM>, and integrity policy <NUM> are examples of host system <NUM>, operating system <NUM>, policy enforcer <NUM>, pod <NUM>, container <NUM>, signature file <NUM>, public key <NUM>, and integrity policy <NUM>, as described above with reference to <FIG>. As also shown in <FIG>, policy enforcer <NUM> comprises a monitor <NUM> and an operation analyzer <NUM>. Monitor <NUM> is an example monitor <NUM>, as described above with reference to <FIG>. As further shown in <FIG>, container engine <NUM> has mounted a file system <NUM>, which is utilized by application <NUM>, and monitor <NUM> comprises an operation detector <NUM> and integrity policy <NUM>. Operation detector <NUM> is an example of operation detector <NUM>, as described above with reference to <FIG>. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart <NUM> and host system <NUM> of <FIG>.

Flowchart <NUM> of <FIG> begins with step <NUM>. In step <NUM>, the application is enabled to execute while enabling an audit mode of the integrity policy in which policy violations caused via execution of the application are detected but enforcement of the integrity policy is disabled. For example, with reference to <FIG>, policy enforcer <NUM> may place integrity policy <NUM> in audit mode. Operation detector <NUM> may detect initiation of execution of application <NUM> via a function call <NUM> that causes application <NUM> to execute and allow function call <NUM> to complete successfully, thereby enabling application <NUM> to execute while integrity policy <NUM> is an audit mode. Function call <NUM> is an example of function call <NUM>, as described above with reference to <FIG>.

In step <NUM>, operations of the application that caused the detected policy violations are analyzed to determine whether the operations are legitimate. If the operations are determined to be illegitimate, flowchart <NUM> continues to step <NUM>. Otherwise, flowchart <NUM> continues to step <NUM>. For example, with reference to <FIG>, operation detector <NUM> may detect various file access operations <NUM> performed by application <NUM> with respect to file system <NUM>. Operation detector <NUM> may determine whether such file access operations <NUM> conform with the rules of integrity policy <NUM>. For instance, if a file access operation violates a rule of the integrity policy <NUM>, operation detector <NUM> logs the violation and information associated with the file access operation into an event log <NUM> via a write command <NUM>. The information may include the type of file access operation (e.g., a read operation, a write operation, a file open operation), the name of the directory and/or file that was accessed, the data that was read from and/or written to the file, etc..

Operation analyzer <NUM> may analyze the violations logged in event log <NUM> to determine whether the associated file access operations are legitimate or illegitimate. For instance, operation analyzer <NUM> may compare the file access operations specified by event log <NUM> to file access operations that are typical of legitimate file access operations and are typical of illegitimate file access operations (e.g., file access operations to files that contain sensitive information such, as user credentials (e.g., usernames, passwords, PIN numbers, credit card numbers, social security numbers, etc.), file access operations that perform a particular sequence of reads and/or writes that is typical of a malicious process (such as a virus, malware, etc.)). If operation analyzer <NUM> determines that file access operations <NUM> are illegitimate, flowchart <NUM> continues to step <NUM>. Otherwise, flowchart <NUM> continues to step <NUM>.

In accordance with an embodiment, operation analyzer <NUM> may utilize machine learning-based techniques that analyze file access operations to determine whether such operations are legitimate or illegitimate. For instance, a file access operation classification model may be generated by training a machine learning-based algorithm on file access operations that are known to be used for malicious (or illegitimate) purposes and file access operations that are known to be used for non-malicious (legitimate) purposes. Using these file access operations, the machine learning-based algorithm learns what constitutes a legitimate file access operation and generates the file access operation classification model. The file access operation classification model is used to classify any file access operation performed by an application (e.g., application <NUM>) as being a legitimate file access operation or an illegitimate file access operation.

At step <NUM>, the integrity policy is maintained. For example, with reference to <FIG>, integrity policy <NUM> is maintained. That is, the rules of integrity policy <NUM> are not changed, and file access operations to files that violate integrity policy <NUM> will be prevented from being performed.

At step <NUM>, the integrity policy is updated to support the operations that cause the detected policy violations, thereby causing such operations to be no longer considered policy violations. For example, with reference to <FIG>, operation analyzer <NUM> may provide an update <NUM> to integrity policy <NUM> that updates the rules of integrity policy <NUM>. Update <NUM> may specify the file access operation(s) that are allowed for one or more particular directories and/or files of file system <NUM>. Accordingly, file access operations that were previously considered illegitimate will be considered legitimate and such file access operations will no longer cause policy violations.

At step <NUM>, the audit mode is disabled. For example, with reference to <FIG>, monitor <NUM> may disable the audit mode of policy <NUM>. Thereafter, all file access operations attempted by application <NUM> must comply with integrity policy <NUM> in order for the operations to complete.

As described above in Subsection A, if a container does not comprise a block device signature, the application associated with the container is prevented from being executed. However, in certain embodiments, unsigned containers may be deployed to a host system and executed thereby. Initially, such containers may be executed while the integrity policy utilized by the policy enforcer (e.g., policy enforcer <NUM>) is in audit mode, as described above in Subsection B. During execution, file access operations performed by the container's application are monitored to determine the behavior of the application. For example, the directories and/or files that are accessed (e.g., opened, written to, and/or read from) by the application are determined and/or analyzed to determine whether such operations are legitimate or illegitimate in a similar fashion as described above in Subsection B. Based on the analysis of the file access operations, an integrity policy is generated for the container that specifies which directories and/or files are accessible to the application. Thereafter, the container is signed with a block device signature by the policy enforcer. The signed container is then re-executed with audit mode disabled. The signed container is then verified for integrity in similar manner as described above with in Subsection A.

Host system <NUM>, operating system <NUM>, container orchestrator <NUM>, container <NUM>, container(s) 110A-11B, signature <NUM>, public key <NUM>, integrity policy <NUM>, pod <NUM>, policy enforcer <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, file system <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, operation detector <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, file system <NUM>, operation detector <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, file system <NUM>, event log <NUM>, and operation detector <NUM>, (and/or any of the components described therein), and/or flowchart <NUM>, <NUM>, <NUM>, <NUM>, and/or <NUM>, may be implemented in hardware, or hardware combined with one or both of software and/or firmware. For example, host system <NUM>, operating system <NUM>, container orchestrator <NUM>, container <NUM>, container(s) 110A-11B, signature <NUM>, public key <NUM>, integrity policy <NUM>, pod <NUM>, policy enforcer <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, file system <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, operation detector <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, file system <NUM>, operation detector <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, file system <NUM>, event log <NUM>, and operation detector <NUM>, (and/or any of the components described therein), and/or flowchart <NUM>, <NUM>, <NUM>, <NUM>, and/or <NUM> may be implemented as computer program code/instructions configured to be executed in one or more processors and stored in a computer readable storage medium.

Alternatively, host system <NUM>, operating system <NUM>, container orchestrator <NUM>, container <NUM>, container(s) 110A-11B, signature <NUM>, public key <NUM>, integrity policy <NUM>, pod <NUM>, policy enforcer <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, file system <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, operation detector <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, file system <NUM>, operation detector <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, file system <NUM>, event log <NUM>, and operation detector <NUM>, (and/or any of the components described therein), and/or flowchart <NUM>, <NUM>, <NUM>, <NUM>, and/or <NUM> may be implemented as hardware logic/electrical circuitry.

For instance, in an embodiment, one or more, in any combination, of host system <NUM>, operating system <NUM>, container orchestrator <NUM>, container <NUM>, container(s) 110A-11B, signature <NUM>, public key <NUM>, integrity policy <NUM>, pod <NUM>, policy enforcer <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, file system <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, operation detector <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, file system <NUM>, operation detector <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, file system <NUM>, event log <NUM>, and operation detector <NUM>, (and/or any of the components described therein), and/or flowchart <NUM>, <NUM>, <NUM>, <NUM>, and/or <NUM> may be implemented together in a SoC. The SoC may include an integrated circuit chip that includes one or more of a processor (e.g., a central processing unit (CPU), microcontroller, microprocessor, digital signal processor (DSP), etc.), memory, one or more communication interfaces, and/or further circuits, and may optionally execute received program code and/or include embedded firmware to perform functions.

<FIG> depicts an exemplary implementation of a computing device <NUM> in which embodiments may be implemented. For example, host systems <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may be implemented in one or more computing devices similar to computing device <NUM> in stationary or mobile computer embodiments, including one or more features of computing device <NUM> and/or alternative features. The description of computing device <NUM> provided herein is provided for purposes of illustration, and is not intended to be limiting. Embodiments may be implemented in further types of computer systems, as would be known to persons skilled in the relevant art(s).

A number of program modules may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. These programs include operating system <NUM>, one or more application programs <NUM>, other programs <NUM>, and program data <NUM>. Application programs <NUM> or other programs <NUM> may include, for example, computer program logic (e.g., computer program code or instructions) for implementing any of the features of host system <NUM>, operating system <NUM>, container orchestrator <NUM>, container <NUM>, container(s) 110A-11B, signature <NUM>, public key <NUM>, integrity policy <NUM>, pod <NUM>, policy enforcer <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, file system <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, operation detector <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, signature checker <NUM>, signature validator <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, file system <NUM>, operation detector <NUM>, host system <NUM>, operating system <NUM>, policy enforcer <NUM>, monitor <NUM>, integrity policy <NUM>, pod <NUM>, container <NUM>, signature <NUM>, public key <NUM>, integrity policy <NUM>, application <NUM>, dependencies <NUM>, container engine <NUM>, file system <NUM>, event log <NUM>, and operation detector <NUM>, (and/or any of the components described therein), and/or flowchart <NUM>, <NUM>, <NUM>, <NUM>, and/or <NUM>, and/or further embodiments described herein.

A user may enter commands and information into computing device <NUM> through input devices such as keyboard <NUM> and pointing device <NUM>.

A method performed by an operating system for enforcing an integrity policy for a container managed by the operating system is described herein. The method comprises: determining whether a block device signature is associated with a container that packages an application and dependencies that enable the application to execute, the block device signature also associated with the application and the dependencies as a result of being associated with the container; in response to determining that the block device signature is associated with the container: determining whether the block device signature is valid; in response to determining that the block device signature is valid, monitoring initiation of execution of the application and file access operations performed by the application for compliance with the integrity policy; and in response to determining that the block device signature is invalid, preventing execution of the application; and in response to determining that a block device signature is not associated with the container, preventing execution of the application of the container.

In one embodiment of the foregoing method, said determining whether a block device signature is associated with a container comprises: determining whether a mounted file system of the container that is utilized by the application is signed with the block device signature; in response to determining that the mounted file system is not signed with the block device signature, unmounting the file system, thereby preventing execution of the application; and in response to determining that the mounted file system is signed with the block device signature and that the block device signature is valid, monitoring initiation of execution of the application and file access operations performed by the application for compliance with the integrity policy.

In one embodiment of the foregoing method, said monitoring comprises: detecting initiation of execution of the application; determining whether the application is signed with a valid block device signature; in response to determining that the application is not signed with a valid block device signature, preventing execution of the application; and in response to determining that the application is signed with a valid block device signature, enabling execution of the application.

In one embodiment of the foregoing method, said detecting comprises: hooking a function call that causes the application to execute.

In one embodiment of the foregoing method, said monitoring comprises: detecting a file access operation with respect to a file of a mounted file system of the container; determining whether the file is signed with a valid block device signature; in response to determining that the file is not signed with a valid block device signature, preventing the file access operation from being performed; and in response to determining that the file is signed with a valid block device signature, enabling the file access operation to be completed.

In one embodiment of the foregoing method, said detecting comprises: hooking a function call configured to open the file.

In one embodiment of the foregoing method, the method further comprises: enabling the application to execute while enabling an audit mode of the integrity policy in which policy violations caused via execution of the application are detected but enforcement of the integrity policy is disabled; analyzing operations of the application that caused the detected policy violations to determine whether such operations are legitimate; in response to determining that the operations are legitimate: updating the integrity policy to support the operations that caused the detected policy violations, thereby causing such operations to be no longer considered policy violations; and disabling the audit mode; and in response to determining that the operations are illegitimate, maintaining the integrity policy.

A system is also described herein. The system includes at least one processor circuit; and at least one memory that stores program code configured to be executed by the at least one processor circuit, the program code comprising: a signature checker configured to determine whether a block device signature is associated with a container that packages an application and dependencies that enable the application to execute, the block device signature also associated with the application and the dependencies as a result of being associated with the container, the application of the container being prevented from being executed in response to a determination that the block device signature is not associated with the container; a signature validator configured to, in response to determining that the block device signature is associated with the container, determine whether the block device signature is valid; and a monitor configured to: in response to a determination that the block device signature is valid, monitor initiation of execution of the application and file access operations performed by the application for compliance with an integrity policy; and in response to a determination that the block device signature is invalid, prevent execution of the application.

In one embodiment of the foregoing system, the signature checker is further configured to: determine whether a mounted file system of the container that is utilized by the application is signed with the block device signature; and in response to a determination that the mounted file system is not signed with the block device signature, cause the file system to be unmounted, thereby preventing execution of the application; and wherein the monitor is further configured to, in response to a determination that the mounted file system is signed with the block device signature and that the block device signature is valid, monitor initiation of execution of the application and file access operations performed by the application for compliance with the integrity policy.

In one embodiment of the foregoing system, the program code further comprises an operation detector configured to detect initiation of execution of the application, wherein the signature validator is further configured to determine whether the application is signed with a valid block device signature, and wherein the monitor is further configured to: in response to a determination that the application is not signed with a valid block device signature, prevent execution of the application; and in response to a determination that the application is signed with a valid block device signature, enable execution of the application.

In one embodiment of the foregoing system, the operation detector is configured to detect initiation of execution of the application by hooking a function call that causes the application to execute.

In one embodiment of the foregoing system, the program code further comprises an operation detector configured to detect a file access operation with respect to a file of a mounted file system of the container, wherein the signature validator is further configured to determine whether the file is signed with a valid block device signature, and wherein the monitor is further configured to: in response to a determination that the file is not signed with a valid block device signature, prevent the file access operation from being performed; an in response to a determination that the file is signed with a valid block device signature, enable the file access operation to be completed.

In one embodiment of the foregoing system, the operation detector is configured to detect the file access operation by hooking a function call configured to open the file.

In one embodiment of the foregoing system, the invocation request comprises one or more parameters that specify at least one of a name of the host browser interface or a location from which to load the host browser interface.

In one embodiment of the foregoing system, the program code further comprises: a policy enforcer configured to enable the application to execute while enabling an audit mode of the integrity policy in which policy violations caused via execution of the application are detected but enforcement of the integrity policy is disabled; and an operation analyzer configured to: analyze operations of the application that caused the detected policy violations to determine whether such operations are legitimate; in response to a determination that the operations are legitimate: update the integrity policy to support the operations that caused the detected policy violations, thereby causing such operations to be no longer considered policy violations; and disable the audit mode; and in response to a determination that the operations are illegitimate, maintain the integrity policy.

A computer-readable storage medium having program instructions recorded thereon that, when executed by at least one processor of a computing device, perform a method. The method comprises: determining whether a block device signature is associated with a container that packages an application and dependencies that enable the application to execute, the block device signature also associated with the application and the dependencies as a result of being associated with the container; in response to determining that the block device signature is associated with the container: determining whether the block device signature is valid; in response to determining that the block device signature is valid, monitoring initiation of execution of the application and file access operations performed by the application for compliance with the integrity policy; and in response to determining that the block device signature is invalid, preventing execution of the application; and in response to determining that a block device signature is not associated with the container, preventing execution of the application of the container.

In one embodiment of the foregoing computer-readable storage medium, said determining whether a block device signature is associated with a container comprises: determining whether a mounted file system of the container that is utilized by the application is signed with the block device signature; in response to determining that the mounted file system is not signed with the block device signature, unmounting the file system, thereby preventing execution of the application; and in response to determining that the mounted file system is signed with the block device signature and that the block device signature is valid, monitoring initiation of execution of the application and file access operations performed by the application for compliance with the integrity policy.

In one embodiment of the foregoing computer-readable storage medium, said monitoring comprises: detecting initiation of execution of the application; determining whether the application is signed with a valid block device signature; in response to determining that the application is not signed with a valid block device signature, preventing execution of the application; and in response to determining that the application is signed with a valid block device signature, enabling execution of the application.

In one embodiment of the foregoing computer-readable storage medium, said detecting comprises: hooking a function call that causes the application to execute.

In one embodiment of the foregoing computer-readable storage medium, said monitoring comprises: detecting a file access operation with respect to a file of a mounted file system of the container; determining whether the file is signed with a valid block device signature; in response to determining that the file is not signed with a valid block device signature, preventing the file access operation from being performed; and in response to determining that the file is signed with a valid block device signature, enabling the file access operation to be completed.

In one embodiment of the foregoing computer-readable storage medium, said detecting comprises: hooking a function call configured to open the file.

Claim 1:
A method performed by an operating system (<NUM>) for enforcing an integrity policy for a container managed by the operating system, comprising:
determining (<NUM>) whether a block device signature (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) is associated with a container (110A-110N, <NUM>, <NUM>, <NUM>, <NUM>) that packages an application (<NUM>, <NUM>, <NUM>, <NUM>) and dependencies (<NUM>, <NUM>, <NUM>, <NUM>) that enable the application to execute, the block device signature also associated with the application and the dependencies as a result of being associated with the container;
in response to determining that the block device signature is associated with the container:
determining (<NUM>) whether the block device signature is valid;
in response to determining that the block device signature is valid, monitoring (<NUM>) initiation of execution of the application and file access operations performed by the application for compliance with the integrity policy; and
in response to determining that the block device signature is invalid, preventing (<NUM>) execution of the application; and
in response to determining that a block device signature is not associated with the container, preventing (<NUM>) execution of the application of the container.