Block device signature-based integrity protection for containerized applications

Integrity verification of a containerized application using a block device signature is described. For example, a container deployed to a host system is signed with a single block device signature. 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 its program code 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 that are not properly signed are prevented from executing, thereby protecting the host system from such processes. Moreover, by using a single block device signature for a container, the enforcement of the integrity policy is greatly simplified.

BACKGROUND

As containers become a prevalent mechanism for running cloud applications, they also become a higher-value target for attackers. Container runtimes have numerous known vulnerabilities through which an attacker can gain access to the host machine by breaking out of the container. In the case that a malicious privileged user has compromised the container system, they may attempt to run an executable from the container, causing a breakout which enables access of the host machine or kernel. Another threat involves a malicious user somehow gaining access to the host and attempting to execute code with the intention of extracting data or persisting on the host machine. While conventional techniques utilized for container security can notify a user of a malicious attack, such a notification is often too late, because the host machine or kernel is already compromised at the time of notification.

SUMMARY

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.

DETAILED DESCRIPTION

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.

A. Block Device Signature-Based Protection for Containerized Applications

FIG. 1shows a block diagram of a system100comprising a host system102for hosting and/or executing one or more containers110A-110N, according to an example embodiment. Host system102may 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 system102may also comprise a virtual machine executing on a stationary or mobile computing device. Host system102may be implemented into a cloud-based computing environment. For instance, host system102may 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 co-located (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 inFIG. 1, host system102may comprise an operating system104, container orchestrator106, a container engine108and one or more container(s)110A-110N. Operating system104may manage one or more hardware components (e.g., processor(s), main memory, secondary storage device(s), etc.) and software executing in host system102. Example hardware components of host system102are described in detail below in reference toFIG. 12. Operating system104may comprise one or more components that perform certain tasks relating to the execution of software (e.g., container orchestrator106, container engine108, and/or container(s)110A-110N in host system102. Examples of operating system104include, but are not limited to, MICROSOFT® WINDOWS® Operating System (OS), published by Microsoft Corporation of Redmond, Wash., Apple macOS®, Google Android™, LINUX®, or other UNIX® variants. Each of container(s)110A-110N, container engine108, container orchestrator106, operating system104, and policy enforcer116may be stored and/or executed within a memory (not shown) of host system102.

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

Container engine108may be configured host and/or execute containerized applications, such as container(s)110A-110N, that are deployed thereto via container orchestrator106. Container(s)110A-110N may be created based on corresponding container image(s) (or binary(ies))112A-112N, which are provided to host system102. Container image(s)112A-112N may be provided to host system102by 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 engine108includes, 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 system102) 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 engine108. An application running in a container of container(s)110A-110N is isolated from the rest of host system102and from other containers of container(s)110A-110N. Container(s)110A-110N share operating system104installed in host system102and 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 signature114to 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 signature114) 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.,4kor 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., signature114) to a container image (e.g., container image112A-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 signature114is 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 signature112is required to verify the integrity of the corresponding container. In accordance with an embodiment, each of signatures112is a dm (device mapper)-verity or a fs (file system)-verity signature. Each of container(s)110A-110N also comprises an unchangeable public key118, which is used to verify signature114and confirm that container(s)110A-110N are protected and unchanged.

As further shown inFIG. 1, operating system104may comprise a policy enforcer116. Policy enforcer116may 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 enforcer116may determine whether each of container(s)110A-110B is associated with a signature file (i.e., signature122) that comprises a block-level signature. Signature122represents signature114that has been mapped into memory. If no such file or signature exists, policy enforcer116may prevent a container from executing. If such a file and signature exist, policy enforcer116may be configured to verify the integrity of each of container(s)110A-110N by determining whether signature122is valid based on public key124. Public key124represents public key118that has been mapped into memory. For instance, policy enforcer116may calculate a hash of a container of container(s)112A-112N, decrypt the corresponding signature122to obtain the top-level root hash using the corresponding public key124and compare the calculated hash value with the top-level root hash. If the hash values are the same, then policy enforcer116determines that the container has not been altered.

Policy enforcer116may 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 system104). 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 enforcer116may 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 enforcer116may 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 enforcer116calculates 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 enforcer116enables 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 enforcer116may hook function calls that perform file access operations (e.g., open( )). Upon hooking such a function call, policy enforcer116calculates 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 enforcer116enables 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 inFIG. 1, each of container image(s)112A-112N may further comprise an integrity policy126, and each of container(s)110A-110N may further comprise an integrity policy128, which represents integrity policy126that has been mapped into memory. Integrity policy126and integrity policy128may 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 enforcer116may implement the rules specified by integrity policy128to determine whether container(s)110A-110N comply with integrity policy128. Policy enforcer116may determine that container(s)110A-110N do not comply with integrity policy128if container(s)110A-110N are not signed by the signature defined by integrity policy128and/or by detecting file access operations that do not conform with the file access operation rules of integrity policy128. Any file access operations that violate a rule of integrity policy128may 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 system102may also comprise a block device signature. For example, container orchestrator106and container engine108may each comprise a respective block device signature that is verified by policy enforcer116at the time such components are loaded into memory.

It is further noted that in certain scenarios, each of container image(s)112A-112N and containers110A-110N may not comprise a respective policy126and policy128. In such scenarios, policy enforcer116may 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 enforcer116for all container(s)110A-110N of host system102. 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. 2shows a flowchart200of a method for enforcing an integrity policy for a container managed by the operating system, according to an example embodiment. In an embodiment, flowchart200may be implemented by an operating system, such as by a policy enforcer316of operating system304, as shown inFIG. 3.FIG. 3is a block diagram of a host system300configured to enforce an integrity policy328for a container310managed by operating system304, according to an example embodiment. As shown inFIG. 3, host system300includes operating system304and a pod320. Operating system304comprises policy enforcer316, and pod320may comprise one or more containers (e.g., container310). Container310comprises an application318, application dependencies326, a signature file322, a public key324, and integrity policy328. Host system300, operating system304, policy enforcer316, pod320, container310, signature file322, public key324, and integrity policy328are examples of host system102, operating system104, policy enforcer116, pod120, container110, signature file122, public key124, and integrity policy128, as described above with reference toFIG. 1. As also shown inFIG. 3, policy enforcer316comprises a signature checker302, a signature validator306, and a monitor330. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart200and host system300ofFIG. 3.

Flowchart200ofFIG. 2begins with step202. In step202, 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 flowchart200continues to step204. Otherwise, flowchart200continues to step206. For instance, as shown inFIG. 3, signature checker302may determine whether a block device signature (e.g., signature322) is associated with container310that packages application318and its dependencies326. For example, signature checker302may provide a request312to container310. Responsive to receiving request312, container310may provide a response314to signature checker302that comprises signature file322, public key324and/or integrity policy328. Signature checker302may determine whether signature file322includes a block device signature (in accordance with integrity policy328). If signature file322does not include a block device signature, if response314indicates that no signature file322exists, or if container310does not provide response314, signature checker302may determine that a block device signature is not associated with container310, and flowchart200continues to step204. If signature file322includes a block device signature, signature checker324may determine that signature file322includes a block device signature and provides signature file322and public key324to signature validator and provides integrity policy328to monitor330. Flowchart200then continues to step206.

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 step204, execution of the application of the container is prevented. For example, with reference toFIG. 3, policy enforcer316prevents application318from executing, for example, by unloading container310from memory (i.e., memory of host system300).

In step206, a determination is made as to whether the block device signature is valid. In response to determining that the block device signature is invalid, flowchart200continues to step204. Otherwise, flowchart200continues to step208. For example, with reference toFIG. 3, signature validator306determines whether the block device signature is valid. For example, signature validator306may calculate a hash of container310, decrypt signature of signature file322to obtain the top-level root hash using public key324, and compare the calculated hash value with the top-level root hash. If the hash values are the same, then signature validator306determines that the block device signature is valid and provides an indicator332to monitor330that indicates that the block device signature is valid. Flowchart200then continues to step208. Otherwise, flowchart200continues to step204. Additional details regarding determining whether a block-valid signature is valid is described below with reference toFIGS. 6-9.

In step208, 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 toFIG. 3, responsive to receiving indicator332, monitor330may monitor initiation of execution of application318and file access operations performed by application318for compliance with integrity policy328.

In accordance with one or more embodiments, policy enforcer316may determine whether a block device signature is associated with container310at the time a file system of container310is mounted. For example,FIG. 4shows a flowchart400of a method for determining whether a block device signature is associated with a container, according to an example embodiment. In an embodiment, flowchart400may be implemented by a policy enforcer516, as shown inFIG. 5.FIG. 5is a block diagram of a host system500configured to determine whether a block device signature is associated with a container510, according to an example embodiment. As shown inFIG. 5, host system500includes an operating system504, a container engine508, and a pod520. Operating system502comprises policy enforcer516, and pod520may comprise one or more containers (e.g., container510). Container510comprises an application518, application dependencies526, signature file522, a public key524, and an integrity policy528. Host system500, operating system504, policy enforcer516, pod520, container510, signature file522, public key524, and integrity policy528are examples of host system300, operating system304, policy enforcer316, pod320, container310, signature file322, public key324, and integrity policy328, as described above with reference toFIG. 3. Container engine508is an example of container engine108, as described above with reference toFIG. 1. As also shown inFIG. 5, policy enforcer516comprises a signature checker502, a signature validator506, and a monitor530, which are examples of signature checker302, signature validator306, and monitor330, as respectively described above with reference toFIG. 3. As further shown inFIG. 5, container engine508has mounted a file system534, which is utilized by application518. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart400and host system500ofFIG. 5.

Flowchart400ofFIG. 4begins with step402. In step402, 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 flowchart400continues to step404. Otherwise, flowchart400continues to step406. For instance, with reference toFIG. 5, signature checker302may detect that file system534of container310has been mounted. For example, container engine508may provide an indicator536to signature checker302that notifies signature checker502that file system534has been mounted. Responsive to determining that file system534has been mounted, signature checker502may provide a request512to container310. Responsive to receiving request512, container510may provide a response514to signature checker502that comprises signature file522, public key524and/or integrity policy528. Signature checker502may analyze signature file522to determine whether it comprises a block device signature. If signature file522does not comprise a block device signature, flowchart400continues to step404. Otherwise, signature checker502provides signature file522and public key524to signature validator506and provides policy328to monitor330. Flowchart400then continues to step406.

At step404, the file system is unmounted, thereby preventing execution of the application. For example, with reference toFIG. 5, signature checker502may provide a command to container engine508that causes container engine508to unmount file system534.

At step406, 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 toFIG. 5, signature validator306may determine whether signature file522comprises a valid block device signature. For example, signature validator506may calculate a hash of file system534, decrypt signature of signature file522to obtain the top-level root hash using public key524, and compare the calculated hash value with the top-level root hash. If the hash values are the same, then signature validator506determines that the block device signature is valid. In response, signature validator506may provide an indicator532to monitor530to indicate that monitor530is to monitor container510for initiation of execution of application518and file access operations performed by application518for compliance with integrity policy528. If the hash values are different, policy enforcer516prevents application518from executing, for example, by providing a command to container engine508that causes container engine508to unmount file system532.

FIG. 6shows a flowchart600of a method for determining whether an application is enabled to execute, according to an example embodiment. In an embodiment, flowchart600may be implemented by a policy enforcer716, as shown inFIG. 7.FIG. 7is a block diagram of a host system700configured to determine whether an application718is enabled to execute, according to an example embodiment. As shown inFIG. 7, host system700includes an operating system704, a container engine708, and a pod720. Operating system702comprises a policy enforcer716, and pod720may comprise one or more containers (e.g., container710). Container710comprises application718, application dependencies726, signature file722, a public key724, and an integrity policy728. Host system700, operating system704, policy enforcer716, pod720, container710, signature file722, public key724, and integrity policy728are examples of host system500, operating system504, policy enforcer516, pod520, container510, signature file522, public key524, and integrity policy528, as described above with reference toFIG. 5. Container engine708is an example of container engine508, as described above with reference toFIG. 5. As also shown inFIG. 7, policy enforcer716comprises a signature checker702, a signature validator706, and a monitor730, which are examples of signature checker502, signature validator506, and monitor530, as respectively described above with reference toFIG. 5. As further shown inFIG. 7, monitor730comprises an operation detector738. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart600and host system700ofFIG. 7.

Flowchart600ofFIG. 6begins with step602. In step602, initiation of execution of the application is detected. For example, operation detector738may detect initiation of execution of application718.

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 toFIG. 7, operation detector738may hook a function call736issued by container engine708that causes application718to execute. An example of such a function is the execvc( ) function call, although the embodiments described herein are not so limited. Responsive to hooking function call736, monitor730may provide an indicator740to signature validator706to indicate that signature validation is required.

In step604, 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 container710). If a determination is made that the application is not signed with a valid block device signature, then flowchart600continues to step606. Otherwise, flowchart600continues to step608. For example, with reference toFIG. 7, signature validator706, responsive to receiving indicator740, may calculate a hash of application718, decrypt signature of signature file722(which is an example of signature file522, as described a above with reference toFIG. 6) to obtain the top-level root hash using public key724(which is an example of public key524, as described above with reference toFIG. 5), and compare the calculated hash value with the top-level root hash. If the hash values are the same, then signature validator706determines that the block device signature of application718is valid, and flowchart600continues to step608. If the hash values are different, signature validator706determines that the block device signature of application718is invalid, and flowchart600continues to step606.

At step606, execution of the application is prevented. For example, with reference toFIG. 7, operation detector738may prevent application718from executing by preventing function call736from completing.

At step608, execution of the application is enabled. For example, with reference toFIG. 7, operation detector738may enable execution of application718by enabling function call736to complete.

FIG. 8shows a flowchart800of a method for determining whether a file access operation from an application is authorized to complete, according to an example embodiment. In an embodiment, flowchart800may be implemented by a policy enforcer916, as shown inFIG. 9.FIG. 9is a block diagram of a host system900configured to determine whether a file access operation from an application918is authorized to complete, according to an example embodiment. As shown inFIG. 9, host system900includes an operating system904, a container engine908, and a pod920. Operating system902comprises a policy enforcer916, and pod920may comprise one or more containers (e.g., container910). Container910comprises an application918, application dependencies926, signature file922, a public key924, and an integrity policy928. Host system900, operating system904, policy enforcer916, pod920, container910, signature file922, public key924, and integrity policy928are examples of host system700, operating system704, policy enforcer716, pod720, container710, signature file722, public key724, and integrity policy728, as described above with reference toFIG. 7. Container engine908is an example of container engine708, as described above with reference toFIG. 7. As also shown inFIG. 9, policy enforcer916comprises a signature checker902, a signature validator906, and a monitor930, which are examples of signature checker702, signature validator706, and monitor730, as respectively described above with reference toFIG. 7. As further shown inFIG. 7, container engine708has mounted a file system932, which is utilized by application918, and monitor930comprises an operation detector938. File system932is an example of file system532, as described above with reference toFIG. 5. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart800and host system900ofFIG. 9.

Flowchart800ofFIG. 8begins with step802. In step802, a file access operation with respect to a file of a mounted file system of the container is detected. For example, operation detector938may detect a file access operation936with respect to a file of mounted file system934of container910is 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 toFIG. 9, operation detector938may hook file access operation936, which may be function call issued by container910that is configured to open a file of file system934. An example of such a function is the open( ) function call, although the embodiments described herein are not so limited. Responsive to hooking function call936, monitor930may provide an indicator940to signature validator906to indicate that signature validation is required.

In step804, 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 container910). If a determination is made that the application is not signed with a valid block device signature, then flowchart800continues to step806. Otherwise, flowchart800continues to step808. For example, with reference toFIG. 9, signature validator906, responsive to receiving indicator940signature validator906, may calculate a hash of the file of file system934, decrypt signature of signature file922(which is an example of signature file722, as described a above with reference toFIG. 7) to obtain the top-level root hash using public key924(which is an example of public key724, as described above with reference toFIG. 7), and compare the calculated hash value with the top-level root hash. If the hash values are the same, then signature validator906determines that the block device signature of the file is valid, and flowchart800continues to step808. If the hash values are different, signature validator908determines that the block device signature of the file invalid and flowchart800continues to step806.

At step806, the file access operation is prevented. For example, with reference toFIG. 9, operation detector938may prevent file access operation936from performed by preventing the corresponding function call from completing.

At step808, execution of the application is enabled. For example, with reference toFIG. 9, operation detector938may enable file access operation936to be completed by enabling the corresponding function call to complete.

B. Integrity Policy Updates

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. 10shows a flowchart1000of a method for updating an integrity policy, according to an example embodiment. In an embodiment, flowchart1000may be implemented by a policy enforcer1116, as shown inFIG. 11.FIG. 11is a block diagram of a host system1100configured to update an integrity policy1128, according to an example embodiment. As shown inFIG. 11, host system1100includes an operating system1104and a pod1120. Operating system1102comprises a policy enforcer1116, and pod1120may comprise one or more containers (e.g., container1110). Container1110comprises an application1118, application dependencies1126, signature file1122, a public key1124, and integrity policy1128. Host system1100, operating system1104, policy enforcer1116, pod1120, container1110, signature file1122, public key1124, and integrity policy1128are examples of host system900, operating system904, policy enforcer916, pod920, container910, signature file922, public key924, and integrity policy928, as described above with reference toFIG. 9. As also shown inFIG. 11, policy enforcer1116comprises a monitor1130and an operation analyzer1146. Monitor1130is an example monitor930, as described above with reference toFIG. 9. As further shown inFIG. 11, container engine1108has mounted a file system1134, which is utilized by application1118, and monitor1130comprises an operation detector1138and integrity policy1128. Operation detector1138is an example of operation detector938, as described above with reference toFIG. 9. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart1000and host system1100ofFIG. 11.

Flowchart1000ofFIG. 10begins with step1002. In step1002, 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 toFIG. 11, policy enforcer1116may place integrity policy1128in audit mode. Operation detector1138may detect initiation of execution of application1118via a function call1136that causes application1118to execute and allow function call1136to complete successfully, thereby enabling application1118to execute while integrity policy1128is an audit mode. Function call1136is an example of function call736, as described above with reference toFIG. 7.

In step1004, 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, flowchart1000continues to step1006. Otherwise, flowchart1000continues to step1008. For example, with reference toFIG. 11, operation detector1138may detect various file access operations1140performed by application1118with respect to file system1134. Operation detector1138may determine whether such file access operations1140conform with the rules of integrity policy1128. For instance, if a file access operation violates a rule of the integrity policy1128, operation detector1138logs the violation and information associated with the file access operation into an event log1142via a write command1144. 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 analyzer1146may analyze the violations logged in event log1142to determine whether the associated file access operations are legitimate or illegitimate. For instance, operation analyzer1146may compare the file access operations specified by event log1142to 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 analyzer1146determines that file access operations1140are illegitimate, flowchart1000continues to step1006. Otherwise, flowchart1000continues to step1008.

In accordance with an embodiment, operation analyzer1146may 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., application1118) as being a legitimate file access operation or an illegitimate file access operation.

At step1006, the integrity policy is maintained. For example, with reference toFIG. 11, integrity policy1128is maintained. That is, the rules of integrity policy1128are not changed, and file access operations to files that violate integrity policy1128will be prevented from being performed.

At step1008, 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 toFIG. 11, operation analyzer1146may provide an update1148to integrity policy1128that updates the rules of integrity policy1128. Update1148may specify the file access operation(s) that are allowed for one or more particular directories and/or files of file system1134. 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 step1010, the audit mode is disabled. For example, with reference toFIG. 11, monitor1130may disable the audit mode of policy1128. Thereafter, all file access operations attempted by application1118must comply with integrity policy1128in order for the operations to complete.

C. Integrity Policies for Unsigned Containers

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 enforcer1116) 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.

IV. Example Computer System Implementation

FIG. 12depicts an exemplary implementation of a computing device1200in which embodiments may be implemented. For example, host systems102,300,500,700,900, and1100may be implemented in one or more computing devices similar to computing device1200in stationary or mobile computer embodiments, including one or more features of computing device1200and/or alternative features. The description of computing device1200provided 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).

As shown inFIG. 12, computing device1200includes one or more processors, referred to as processor circuit1202, a system memory1204, and a bus1206that couples various system components including system memory1204to processor circuit1202. Processor circuit1202is an electrical and/or optical circuit implemented in one or more physical hardware electrical circuit device elements and/or integrated circuit devices (semiconductor material chips or dies) as a central processing unit (CPU), a microcontroller, a microprocessor, and/or other physical hardware processor circuit. Processor circuit1202may execute program code stored in a computer readable medium, such as program code of operating system1230, application programs1232, other programs1234, etc. Bus1206represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. System memory1204includes read only memory (ROM)1208and random-access memory (RAM)1210. A basic input/output system1212(BIOS) is stored in ROM1208.

Computing device1200also has one or more of the following drives: a hard disk drive1214for reading from and writing to a hard disk, a magnetic disk drive1216for reading from or writing to a removable magnetic disk1218, and an optical disk drive1220for reading from or writing to a removable optical disk1222such as a CD ROM, DVD ROM, or other optical media. Hard disk drive1214, magnetic disk drive1216, and optical disk drive1220are connected to bus1206by a hard disk drive interface1224, a magnetic disk drive interface1226, and an optical drive interface1228, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computer. Although a hard disk, a removable magnetic disk and a removable optical disk are described, other types of hardware-based computer-readable storage media can be used to store data, such as flash memory cards, digital video disks, RAMs, ROMs, and other hardware storage media.

A user may enter commands and information into computing device1200through input devices such as keyboard1238and pointing device1240. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, a touch screen and/or touch pad, a voice recognition system to receive voice input, a gesture recognition system to receive gesture input, or the like. These and other input devices are often connected to processor circuit1202through a serial port interface1242that is coupled to bus1206, but may be connected by other interfaces, such as a parallel port, game port, or a universal serial bus (USB).

A display screen1244is also connected to bus1206via an interface, such as a video adapter1246. Display screen1244may be external to, or incorporated in computing device1200. Display screen1244may display information, as well as being a user interface for receiving user commands and/or other information (e.g., by touch, finger gestures, virtual keyboard, etc.). In addition to display screen1244, computing device1200may include other peripheral output devices (not shown) such as speakers and printers.

Computing device1200is connected to a network1248(e.g., the Internet) through an adaptor or network interface1250, a modem1252, or other means for establishing communications over the network. Modem1252, which may be internal or external, may be connected to bus1206via serial port interface1242, as shown inFIG. 12, or may be connected to bus1206using another interface type, including a parallel interface.

As noted above, computer programs and modules (including application programs1232and other programs1234) may be stored on the hard disk, magnetic disk, optical disk, ROM, RAM, or other hardware storage medium. Such computer programs may also be received via network interface1250, serial port interface1242, or any other interface type. Such computer programs, when executed or loaded by an application, enable computing device1200to implement features of embodiments discussed herein. Accordingly, such computer programs represent controllers of the computing device1200.

III. Additional Example Embodiments

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.